[Bug 173541] High (0.60+, 1.00) idle load averages

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541

--- Comment #41 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to Stavros Filargyropoulos from comment #39)

I've not looked at anything approaching a single
hardware thread environment to observe what the
load averages would be like (for the same type
of cores run at the same sort of rates and other
things being comparable). The closest I could
test is 4 core instead of 16 core (MACCHIATObin
Double Shot vs. the HoneyComb, same boot media
used would be possible, still 4 GiBytes of RAM
per core: 16 GiBytes).

It is not obvious to me that varying just the
hardware thread count leaves the load average as
it is in my context. The above test would vary
somewhat more then just the hardware thread count.
But it would be fairly close as far as I know.

I can say that a full load (no backlog) on the
HoneyComb would be load average 16: the core
count (nothing analogous to hyperthreading
is involved).

0.20/16 == 0.0125 == 1/80, so 79 of 80 "units" are
available for other uses in such a crude comparison.
I'm never likely to notice the difference vs. 80 out
of 80 "units" being available for use.

If 4 cores also got 0.20 for the load average:
0.20/4 == 0.05 == 1/20 == 4/80, so 76 of 80 "units"
left. That would be less left for other activity,
but I'm still not likely to significantly notice vs.
80 out of 80.

Of course, if 4 cores gets, say, 0.80 for a load
average when "idle" that would be different. But
I do not remember noticing such load averages on
idle 4 core systems that are similar to the
HoneyComb in other ways. May be I'll test at some
point so general memory from activity not focused
on the issue is not involved.

I'm not claiming 0.20 or 0.80 would be good
approximations: illustrations only.

Another point is: if the machine is not near or
beyond being fully in use (all hardware threads),
I'm even less likely to notice the activity that
is associated with idle: the parallelism avoids
most direct-tradeoff time conflicts.

-- 
You are receiving this mail because:
You are the assignee for the bug.