Re: How can this 'top' command output make sense? Load over 7 and total CPU use ~5%



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].  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
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.  It's clear from the top output that his machine
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?  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 data
it makes no sense to block other processes.  Waiting 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...  It
helps if the working set is already in the L3 cache -- so having the correct
amount[*] of cache RAM available is an important design criterion.

Makes sense.

--
Glen Barber
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • IPv6 oops on ifup in latest BK
    ... Using ACPI for SMP configuration information ... Initializing CPU#0 ... CPU: Trace cache: 12K uops, ...
    (Linux-Kernel)
  • SCSI CDROM issue in kernels >= 2.6.14-rc3
    ... CPU: Trace cache: 12K uops, ... MEM window: disabled. ... SCSI device sda: 17928698 512-byte hdwr sectors ...
    (Linux-Kernel)
  • mptscsih: ioc1: attempting task abort! (sc=d6e8a980)
    ... CPU 2: Machine Check Exception: 0000000000000004 ... OEM ID: INTEL Product ID: Bridge CRB APIC at: 0xFEE00000 ... CPU: Trace cache: 12K uops, ... SCSI device sda: 287132440 512-byte hdwr sectors ...
    (Linux-Kernel)
  • Re: 2.6.16-rc6-mm2
    ... CPU: Trace cache: 12K uops, ... Calibrating delay using timer specific routine.. ... # ACPI Support ...
    (Linux-Kernel)
  • 2.6.16-rc5 huge memory detection regression
    ... I just tested 2.6.16-rc5 kernel on MSI 9136 dual Xeon server motherboard with 16 GB of memory and the kernel detects only 8 GB of RAM instead. ... CPU: Trace cache: 12K uops, ... SCSI device sda: 390721968 512-byte hdwr sectors ...
    (Linux-Kernel)