From owner-freebsd-hackers Sat Jun 12 20:20:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id A168514C9E for ; Sat, 12 Jun 1999 20:20:08 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (qmail 19300 invoked from network); 13 Jun 1999 03:20:07 -0000 Received: from dyson.iquest.net (198.70.144.127) by iquest3.iquest.net with SMTP; 13 Jun 1999 03:20:07 -0000 Received: (from root@localhost) by dyson.iquest.net (8.9.1/8.9.1) id WAA05857; Sat, 12 Jun 1999 22:20:05 -0500 (EST) From: "John S. Dyson" Message-Id: <199906130320.WAA05857@dyson.iquest.net> Subject: Re: High syscall overhead? In-Reply-To: <199906130250.TAA02805@mag.ucsd.edu> from Bill Huey at "Jun 12, 99 07:50:05 pm" To: billh@mag.ucsd.edu (Bill Huey) Date: Sat, 12 Jun 1999 22:20:05 -0500 (EST) Cc: dyson@iquest.net, freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Think of it like this: since alot of desktops sit in idle loops much > > of the time, perhaps the Linux philosophy has been to improve such > > behavior :-). > > The Linux philosophy already has better performance and will also get > you much stronger TCP/IP user land copy performance under SMP since > it releases locks around the data copy. > In a general sense, FreeBSD will still outperform Linux, however in SMP, FreeBSD is behind... It is alot of fun to look towards the "new" linux VM code, "can you say tweak, tweak???" This is a perfect example of coding vs. design. There is NO need for explicit policies (steal a page here or there in specific places.) When DG and I were first playing with the code, DG admonished me continually to avoid nonsense "policies" and that is probably a very significant contribution in the end. We ended up with a scheme that develops it's own policy, and it is difficult to track what the system is doing, let alone "control" it better than the system can do itself. Note that in a non-trivial WWW server, the system isn't waiting on TCP, but is dealing with CGI. I suspect that it would be very useful for the FreeBSD team for Linux to "improve" their SMP. I hope they create really fine grained locks all over the place... With all of those fine grained locks, they can expand the domain of the optimized spin loop :-). John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message