public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Gerst <bgerst@didntduck.org>
To: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@suse.de>
Subject: Re: [PATCH] Fix hotplug cpu on x86_64
Date: Fri, 07 Oct 2005 11:27:52 -0400	[thread overview]
Message-ID: <434693F8.3070706@didntduck.org> (raw)
In-Reply-To: <19D0D50E9B1D0A40A9F0323DBFA04ACCE04D9C@USRV-EXCH4.na.uis.unisys.com>

Protasevich, Natalie wrote:
>>Brian Gerst wrote:
>>
>>>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.
>>
> 
> I had to do the same in i386, but initially I was trying to avoid the
> whole situation - allocating per_cpu data for all possible processors.
> It seemed wasteful that on the system with NR_CPU=256 or 512 and brought
> up as 4x everything per_cpu is (pre)allocated for all, although it's
> sure convenient. I though at the time it would be great if
> alloc_percpu() mechanism was able to dynamically re-create all the
> per_cpu's for new processors, that way cpu_possible_map woun't probably
> even be needed. Or is it too much trouble for too little gain...
> 
> Thanks,
> --Natalie
> 

It certainly is possible.  In the hotplug cpu case, don't put the 
.data.percpu section in __initmem.  It will then be preserved for any 
cpus that come online after boot.

--
				Brian Gerst

  reply	other threads:[~2005-10-07 15:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-07 15:07 [PATCH] Fix hotplug cpu on x86_64 Protasevich, Natalie
2005-10-07 15:27 ` Brian Gerst [this message]
2005-10-07 16:24 ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2005-10-07 16:42 Protasevich, Natalie
2005-10-07 17:25 ` Andi Kleen
2005-10-07 16:00 Protasevich, Natalie
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
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=434693F8.3070706@didntduck.org \
    --to=bgerst@didntduck.org \
    --cc=Natalie.Protasevich@UNISYS.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox