From owner-freebsd-hackers Sat Jun 12 13:23: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 5378B14BFA for ; Sat, 12 Jun 1999 13:23:07 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id NAA16231; Sat, 12 Jun 1999 13:14:59 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA05865; Sat, 12 Jun 1999 13:14:59 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA16642; Sat, 12 Jun 99 13:14:30 PDT Message-Id: <3762BFA6.B46F8C39@softweyr.com> Date: Sat, 12 Jun 1999 14:14:30 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Soren Schmidt Cc: Arun Sharma , dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: High syscall overhead? References: <199906121844.UAA14011@freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Soren Schmidt wrote: > > It seems Arun Sharma wrote: > > An alternative way, which requires a good understanding of both the > > theory and implementation of the kernel is - > > > > (a) Implement per subsystem locking > > This was exactly what I experimented with some 7-8 month ago, it > showed significant improvements in performance, yet it was relatively > easy to do. > > > (b) Figure out in a "typical" workload, how much time is being spent > > in which subsystem and try increasing parallelism (i.e. finer > > grained locking) in subsystems where more time is being spent. > > Well, my simple tests showed no need for this, again its a fine > balance between spending the time waiting, and spending the time > processing locks. Implementing some (optional) benchmarking code for the locks would make it pretty simple to do this as a follow-on project, once the initial "several-sorta-big-locks" project is stable. There's always room for improvement. > > The result of this approach should be more logical, cleaner and > > possibly better performing than the previous one. > > It sure is easier to understand and to maintain. Maybe I should > try it again, and this time keep off-site backups :) I have disk space available. ;^) Actually, I have a DLT drive available now, too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message