Date: Sun, 24 May 2009 05:47:12 -0400 From: Glen Barber <glen.j.barber@gmail.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: How can this 'top' command output make sense? Load over 7 and total CPU use ~5% Message-ID: <4ad871310905240247v50b44fa6pd99c22c9c6516908@mail.gmail.com> In-Reply-To: <4A190E47.6080006@infracaninophile.co.uk> References: <4A18BEC8.5060506@rawbw.com> <4A18FB5B.4080902@infracaninophile.co.uk> <4ad871310905240112n6186631awd96599ab51886506@mail.gmail.com> <4A190E47.6080006@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 24, 2009 at 5:07 AM, Matthew Seaman wrote: >> >> I thought, if it was a dual-core for example, a load average of 1.00 >> would indicate 50% CPU utilization overall (1 process using only 1 >> core)[1]. =A02.00 on a dual-core would be 100%, 3.00 on a dual-core >> would be 100% utilization, and always 1 process in the wait queue, and >> so on. > > It seems both ways have been used in different OSes, which is confusing. > A quick test of a single threaded process that will spin one CPU on a > multi-core FreeBSD box shows the value is /not/ scaled by the number of > cores. > Meaning a load average of 1.00 on a single-core versus dual-core means the same thing? I can't tell if you said what I said (or meant) with different wording, or if you said the opposite. :-) > Which means that the LA the OP was talking about is actually a lot less > alarming > than it originally appears. =A0It's clear from the top output that his ma= chine > has at least 8 cores, so a LA of 7 is really not very heavily loaded. > So in this situation, he has 1 core idle all of the time, correct? >> >> Does this affect the load average though? =A0My understanding was that >> if the CPU cannot immediately process data, the data gets put into the >> wait queue until L2 Cache (then RAM, etc, etc) returns the data to be >> processed. > > Yes it does: when a process is on the CPU and blocked waiting for IO > it does not necessarily yield the CPU to another process. =A0It depends o= n > timescales -- obviously if the CPU will have to wait milliseconds for dat= a > it makes no sense to block other processes. =A0Waiting a few microseconds= is > a different matter though: it might take that long to load up L2/L3 cache > with that processes' working data, so yielding the CPU for that sort of > delay > would mean the process never got run, which is counter productive... =A0I= t > helps if the working set is already in the L3 cache -- so having the corr= ect > amount[*] of cache RAM available is an important design criterion. Makes sense. --=20 Glen Barber
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ad871310905240247v50b44fa6pd99c22c9c6516908>