Bug 169983 - nonsensical load average on AMD64 SMP
Summary: nonsensical load average on AMD64 SMP
Status: CLOSED DUPLICATE of bug 169962
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-06 03:59 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

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

Attachments (Terms of Use)

Description Alexandre Oliva 2005-10-06 03:59:26 UTC
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 05:19:10 UTC

*** 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.