From owner-freebsd-hackers Thu Jan 28 16:28:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA17160 for freebsd-hackers-outgoing; Thu, 28 Jan 1999 16:28:02 -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 QAA17125 for ; Thu, 28 Jan 1999 16:27:56 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 29685 invoked from network); 29 Jan 1999 00:26:19 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 29 Jan 1999 00:26:19 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id TAA22366; Thu, 28 Jan 1999 19:26:14 -0500 (EST) Message-Id: <199901290026.TAA22366@y.dyson.net> Subject: Re: High Load cron patches - comments? In-Reply-To: <199901281929.LAA10380@apollo.backplane.com> from Matthew Dillon at "Jan 28, 99 11:29:44 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 28 Jan 1999 19:26:14 -0500 (EST) Cc: dyson@iquest.net, wes@softweyr.com, toasty@home.dragondata.com, 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: > :> at once. > :> > :> If 150 sendmails are fork instantly, the machine glitches for about > :> 2 seconds. > :> > :Is that "good enough"? Why isn't a solution that allows for really good > :sendmail performance, and also almost no glitch superior? I propose that > :it is possible to produce an almost hands free (easy to administer) mechanism > :that is quite superior to that. > : > :There are "batch" advantages to the same text pages being used over and > :over again, but the system is going to be in a CPU cache thrash state anyway > :when forking 150 sendmails. The buffer cache won't necessarily be thrashed, > :but the occupancy of data in the buffer cache is much longer anyway. > : > :-- > :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. > > Users notice load. The size of the spike doesn't matter... it's how > long it lasts that matters. I.e. I would rather a machine's load tripple > or quadruple for a few minutes then see it double for twice as long. > I would rather that *even* if I loose a little performance/efficiency. > Isn't it more the lack of responsiveness that matters? I mean, it is the missing shell prompt, more than the long term amount of CPU that they can get, right? If the scheduler is good, the users will notice load only as a longer term artifact, but short term, the realtime response is still snappy. By providing a sluggish behavior for trivial operations, there is obviously a bias against them, since the trivial operations often don't even use up their quantum, and many of those operations take much less time to run, than the delay imposed due to system loading conditions. Quantifying load as being "double" depends on the measurement method. Note that "loadaverage" as a load isn't very useful for short term responsiveness. By specifying the goals for the scheduler (end user requirements), it is quite possible to maintain a responsive shell, while a system is very heavily loaded in the traditional loadaverage sense. It is also possible to have a heavily loaded system (short term), while the system appears to be lightly loaded in a loadaverage sense. The above issues are true for the CPU scheduler, but there are such issues for other items (like paging rates or memory) also. -- 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