From owner-freebsd-current Tue Apr 4 2:47:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from ferret.lmh.ox.ac.uk (ferret.lmh.ox.ac.uk [163.1.138.204]) by hub.freebsd.org (Postfix) with SMTP id 11B6537B5EF for ; Tue, 4 Apr 2000 02:47:15 -0700 (PDT) (envelope-from xelah@ferret.lmh.ox.ac.uk) Received: (qmail 10089 invoked by uid 2036); 4 Apr 2000 09:47:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Apr 2000 09:47:02 -0000 Date: Tue, 4 Apr 2000 10:47:02 +0100 (BST) From: Alex Hayward To: current@FreeBSD.ORG Subject: Re: Load average calculation? In-Reply-To: <00040316084601.08733@nomad.dataplex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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