From: Andi Kleen <ak@suse.de>
To: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com>
Cc: "Brian Gerst" <bgerst@didntduck.org>,
"lkml" <linux-kernel@vger.kernel.org>,
"Andrew Morton" <akpm@osdl.org>
Subject: Re: [PATCH] Fix hotplug cpu on x86_64
Date: Fri, 7 Oct 2005 19:25:30 +0200 [thread overview]
Message-ID: <200510071925.30859.ak@suse.de> (raw)
In-Reply-To: <19D0D50E9B1D0A40A9F0323DBFA04ACCE04D9E@USRV-EXCH4.na.uis.unisys.com>
On Friday 07 October 2005 18:42, Protasevich, Natalie wrote:
> You know Andi, I was imagining something like bitmap or linked list of
> all per_cpu vars (dynamically updated) and just going through this
> list... Or something like that (maybe some registration mechanism).
> There are not too many of them - about two dozens, mostly all sorts of
> accounting.
Finding them is no problem. We have NR_CPUS arrays for this (or other
per CPU mechanisms).
The problem is initializing them correct. There are currently two ways to do
this:
- (easier one, used by most subsystems) at startup set up state for
all possible CPUs.
- (complex one) register a CPU notifier and watch for CPU_UP/DOWN
Because of the first way the per cpu data is currently preallocated for
all hotplug CPUs. You cannot copy the state later because it might be
undefined then.
To make dynamic changes of possible map work would require to convert all
users to the second more complex way. Probably a lot of work.
>
> > I think it is better to try to figure out how many hotplug
> > CPUs are supported, otherwise use a small default.
>
> Exactly - such as on ES7000, it can support 32, 64, 128 etc. processors
> depending on what configuration the customer actually ordered :)... it
> should be something for that, then NR_CPUS could be either defined as
> boot parameter or belong to subarchs.
ACPI/mptables has the concept of "disabled" CPUs. I just bent that a bit
and use it as the number of possible CPUs.
-Andi
next prev parent reply other threads:[~2005-10-07 17:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-07 16:42 [PATCH] Fix hotplug cpu on x86_64 Protasevich, Natalie
2005-10-07 17:25 ` Andi Kleen [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-10-07 16:00 Protasevich, Natalie
2005-10-07 15:07 Protasevich, Natalie
2005-10-07 15:27 ` Brian Gerst
2005-10-07 16:24 ` Andi Kleen
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=200510071925.30859.ak@suse.de \
--to=ak@suse.de \
--cc=Natalie.Protasevich@unisys.com \
--cc=akpm@osdl.org \
--cc=bgerst@didntduck.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