Bug 169983 - nonsensical load average on AMD64 SMP
nonsensical load average on AMD64 SMP
Status: CLOSED DUPLICATE of bug 169962
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-10-05 23:59 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-06 01:19:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2005-10-05 23:59:26 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b4) Gecko/20050915 Fedora/1.5-0.5.0.beta1 Firefox/1.4

Description of problem:
$ uptime; sleep 5; uptime
 00:54:54 up 50 min,  9 users,  load average: 189451.99, 137666.98, -444284.58
 00:54:59 up 50 min,  9 users,  load average: -440573.58, 267158.71, 625579.97

Need I say more? :-)

Load varies wildly pretty much forever.  If you're lucky, leaving the actual load close to 0 for some time from a half hour to 4 hours gets the first load average to a reasonable number, enabling mail delivery et al, but sometimes it stabilizes at a very large number instead.  Even after it stabilizes, random load fluctuations may cause it to get wild again.

Version-Release number of selected component (if applicable):
kernel-2.6.13-1.1594_FC5 (started at kernel-2.6.13-1.1580_FC5 or so; 1578 didn't have it for sure)

How reproducible:

Steps to Reproduce:
1.Boot up a UP Athlon64 notebook

Actual Results:  Load average numbers are nonsensical.  The load distribution printed by top doesn't seem reasonable either.

Expected Results:  1578 had it right

Additional info:

Brian Gerst <bgerst@didntduck.org> mentioned this problem on lkml one or two days ago, saying it only occurred with SMP enabled in the kernel build (like the default x86_64 kernel).  Today, he followed up:

I found the culprit: CPU hotplug.  The problem is that
prefill_possible_map() is called after setup_per_cpu_areas().  This
leaves the per-cpu data sections for the future cpus uninitialized
(still pointing to the original per-cpu data, which is initmem).
Since the cpus exists in cpu_possible_map, for_each_cpu will iterate
over them even though the per-cpu data is invalid.
Comment 1 Dave Jones 2005-10-06 01:19:10 EDT

*** This bug has been marked as a duplicate of 169962 ***

Note You need to log in before you can comment on or make changes to this bug.