Date: Tue, 4 Apr 2000 10:47:02 +0100 (BST) From: Alex Hayward <xelah@ferret.lmh.ox.ac.uk> To: current@FreeBSD.ORG Subject: Re: Load average calculation? Message-ID: <Pine.LNX.4.21.0004041025510.27546-100000@ferret.lmh.ox.ac.uk> In-Reply-To: <00040316084601.08733@nomad.dataplex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2000, Richard Wackerbarth wrote: > On Mon, 03 Apr 2000, Donn Miller wrote: > > > I think we ought to re-examine the definition of load average. By > > load, we mean an actual load on the cpu, and waiting processes aren't > > really exerting a cpu load. So, by that reasoning I say waiting > > processes don't count. > > I think you have an incorrect (incomplete) definition. > > Traditionally, the load was the number of processes WANTING to run. > Tasks which are waiting for "user" I/O are excluded. > However, tasks waiting to be swapped in should be counted. This sounds to me like the right approach from point of view of a program like sendmail that reacts to load average. If you get in to a position in which the system is spending all of its time accessing the disc (so that the number of processes actually USING the CPU is quite low 'cos they are all waiting for pages to be swapped back in) is launching off yet more work /really/ the right thing to do? If all it does is result in even more thrashing then couldn't that actually *cut* the load average as calculated using the first of those definitions and push the system even further into the quagmire? OK, so you could easily argue that load average is a far from perfect measure for something of this sort but the second definition does sound more useful IMHO...it gives a better measure of the number of processes which can't yet complete their next chunk of work because of limited system resources. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0004041025510.27546-100000>