From owner-freebsd-hackers Sat Jun 12 11: 9:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id E765214E84 for ; Sat, 12 Jun 1999 11:09:49 -0700 (PDT) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: from c62443-a.frmt1.sfba.home.com ([24.0.69.165]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990612180949.QRZF8807.mail.rdc1.sfba.home.com@c62443-a.frmt1.sfba.home.com>; Sat, 12 Jun 1999 11:09:49 -0700 Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.8.7/8.8.7) id LAA26052; Sat, 12 Jun 1999 11:09:49 -0700 To: dyson@iquest.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: High syscall overhead? References: <199906121653.LAA06434@dyson.iquest.net.> From: Arun Sharma Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: 12 Jun 1999 11:09:48 -0700 In-Reply-To: "John S. Dyson"'s message of "Sat, 12 Jun 1999 11:53:27 -0500 (EST)" Message-ID: Lines: 35 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "John S. Dyson" writes: > Finegrained locking either requires developers with IQ's of 200 or higher, > or a different kernel structure. I suggest that finegrained locking is cool, > and can be intelligently used to mitigate (but not solve) the effects of > lots of problems Fine grained locking is hard - but it isn't exactly rocket science. It's been tackled in a number of OSes, papers have been written about it. > -- however, it would be unwise to embark on an effort to make > the FreeBSD kernel into an efficent 16way SMP kernel by using finegrained > locking all over the place. Sure. But 2 and 4-way boxes are becoming more and more mainstream. And any IO bound job is not going to perform well on FreeBSD because of giant locking. One way of tackling the problem is - to implement per lock profiling and detect which locks are being contested heavily and try breaking them down. That would be a practical way of doing things. An alternative way, which requires a good understanding of both the theory and implementation of the kernel is - (a) Implement per subsystem locking (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. The result of this approach should be more logical, cleaner and possibly better performing than the previous one. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message