All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Gerst <bgerst@didntduck.org>
To: Andi Kleen <ak@suse.de>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: Bogus load average and cpu times on x86_64 SMP kernels
Date: Wed, 05 Oct 2005 14:00:36 -0400	[thread overview]
Message-ID: <434414C4.8020109@didntduck.org> (raw)
In-Reply-To: <43437DEB.4080405@didntduck.org>

Brian Gerst wrote:
> I've been seeing bogus values from /proc/loadavg on an x86-64 SMP kernel 
> (but not UP).
> 
> $ cat /proc/loadavg
> -1012098.26 922203.26 -982431.60 1/112 2688
> 
> This is in the current git tree.  I'm also seeing strange values in 
> /proc/stat:
> 
> cpu  2489 40 920 60530 9398 171 288 1844674407350
> cpu0 2509 60 940 60550 9418 191 308 0
> 
> The first line is the sum of all cpus (I only have one), so it's picking 
> up up bad data from the non-present cpus.  The last value, stolen time, 
> is completely bogus since that value is only ever used on s390.
> 
> It looks to me like there is some problem with how the per-cpu 
> structures are being initialized, or are getting corrupted.  I have not 
> been able to test i386 SMP yet to see if the problem is x86_64 specific.

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.

--
				Brian Gerst

  reply	other threads:[~2005-10-05 18:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-05  7:16 Bogus load average and cpu times on x86_64 SMP kernels Brian Gerst
2005-10-05 18:00 ` Brian Gerst [this message]
2005-10-07  4:15   ` [PATCH] Fix hotplug cpu on x86_64 Brian Gerst
2005-10-07  9:50     ` Andi Kleen
2005-10-08  0:50       ` Anton Blanchard
2005-10-08 10:33         ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=434414C4.8020109@didntduck.org \
    --to=bgerst@didntduck.org \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.