From owner-freebsd-hackers Sat Jun 12 11:44:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 6455614D92 for ; Sat, 12 Jun 1999 11:44:41 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id UAA14011; Sat, 12 Jun 1999 20:44:31 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199906121844.UAA14011@freebsd.dk> Subject: Re: High syscall overhead? In-Reply-To: from Arun Sharma at "Jun 12, 1999 11: 9:48 am" To: adsharma@home.com (Arun Sharma) Date: Sat, 12 Jun 1999 20:44:31 +0200 (CEST) Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. > 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 :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message