Date: Sun, 24 May 2009 10:07:19 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Glen Barber <glen.j.barber@gmail.com> 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: <4A190E47.6080006@infracaninophile.co.uk> In-Reply-To: <4ad871310905240112n6186631awd96599ab51886506@mail.gmail.com> References: <4A18BEC8.5060506@rawbw.com> <4A18FB5B.4080902@infracaninophile.co.uk> <4ad871310905240112n6186631awd96599ab51886506@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig34D09B1C3A50F8CD2536B96F
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Glen Barber wrote:
> Hi, Matthew
>=20
> On Sun, May 24, 2009 at 3:46 AM, Matthew Seaman
> <m.seaman@infracaninophile.co.uk> wrote:
>> Yuri wrote:
>=20
> [snip]
>=20
>> Sure. This is not an uncommon occurrence really. The load average is
>> the number of processes in the queue for a CPU time slice averaged ove=
r
>> 5, 10 or 15 minutes. For multi-core systems the LA is scaled by the n=
umber
>> of cores so a LA of 1.0 means all cores have active processes pretty m=
uch
>> continually.
>>
>=20
> 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]. 2.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 c=
ores.
Which means that the LA the OP was talking about is actually a lot less a=
larming
than it originally appears. It's clear from the top output that his mach=
ine
has at least 8 cores, so a LA of 7 is really not very heavily loaded.
>> Now, you might think that an active process will take the CPU utilisat=
ion
>> to 100%, but that is not necessarily so. Some numerical applications =
can
>> do that, but purely CPU bound processes are relatively uncommon in eve=
ryday
>> usage. In actuality what happens is that the processor will need to
>> retrieve
>> data from somewhere to operate on. There's a hierarchy of data stores=
of
>> various speeds (latency, rather than bandwidth):
>>
>> L1 Cache > L2 Cache > L3 Cache > Main RAM > Disk > Network
>>
>=20
> Does this affect the load average though? My 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. It depends on
timescales -- obviously if the CPU will have to wait milliseconds for dat=
a
it makes no sense to block other processes. Waiting a few microseconds i=
s
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 d=
elay
would mean the process never got run, which is counter productive... It
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. It's =
something
that Intel was shown to have got wrong with some of the Pentium series ch=
ips
when a low powered Pentium M designed for mobile use smoked a much higher=
clock speed Pentium chip designed for all-out server use simply because i=
t had
about 4x as much cache.
Cheers,
Matthew
[*] ie. as much as possible.
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enig34D09B1C3A50F8CD2536B96F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkoZDk0ACgkQ8Mjk52CukIwQGACeJpPI3T5mjoJNi230nUl955SW
LkQAnjYsfZbseoMsyyIgN5MzdnMf3fbI
=ehSj
-----END PGP SIGNATURE-----
--------------enig34D09B1C3A50F8CD2536B96F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A190E47.6080006>