From owner-freebsd-hackers Tue Jan 26 13:10:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA00498 for freebsd-hackers-outgoing; Tue, 26 Jan 1999 13:10:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA00472 for ; Tue, 26 Jan 1999 13:10:02 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 14982 invoked from network); 26 Jan 1999 21:09:58 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 26 Jan 1999 21:09:58 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id QAA01076; Tue, 26 Jan 1999 16:09:58 -0500 (EST) Message-Id: <199901262109.QAA01076@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901262044.MAA21318@apollo.backplane.com> from Matthew Dillon at "Jan 26, 99 12:44:27 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 26 Jan 1999 16:09:58 -0500 (EST) Cc: dhw@whistle.com, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Matthew Dillon said: > > I did a huge amount of playing around with FreeBSD's scheduler back > in the 'early days' of BEST ( we were actually running FreeBSD for a bit > before we made the SGI blunder ). In those days, our two shell machines > were running at a constant load of 15 or more. > > I tried all sorts of stuff, but none of it performed significantly better > then the existing scheduler. And, as cpu speeds started to increase, > it became less and less of an issue. > Back in the very early days of FreeBSD (around 1.1), I noticed that interactive performance was poor (relative to SVR3.) When reviewing the scheduler code (actually the fork code), I saw that on a session basis, a user could "boost" their priority by performing fork operations. Those fork operations forgot previous CPU usage. In order to provide smooth performance, I added a cpu scheduler stats accumulation for the parent process so that the "session" would appear to have consistant cpu usage, and therefor consistant running priority. For most if it's life, FreeBSD has had this change, and does demonstrate that small changes in the scheduler behavior can have a significant effect on perceived performance. Now, a parent process accumulates the effects of it's children (upon their exit) so that there is no apparent priority boost, and more smooth interative behavior. Note that SVR4 with it's new scheduler (at the time) has the same problem that FreeBSD originally did. On retrospect, I reviewed SVR3 and found that it had a similar mechanism that I added to FreeBSD for recent cpu usage reverse inheritance from children to parent. Recently, NetBSD broke that reverse inheritance (that they either borrowed from FreeBSD, or developed independently), and there were cries about the terrible interactive performance!!! Of course, they fixed it ASAP... -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message