Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: [PATCH] Fix hotplug cpu on x86_64
Date: Fri, 7 Oct 2005 11:42:13 -0500
Message-ID: <19D0D50E9B1D0A40A9F0323DBFA04ACCE04D9E@USRV-EXCH4.na.uis.unisys.com>
Thread-Topic: [PATCH] Fix hotplug cpu on x86_64
Thread-Index: AcXLW6UodDBLoWAWSX+zV2HuL5ahCgAAExwQ
From: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
To: "Andi Kleen" <ak@suse.de>
Cc: "Brian Gerst" <bgerst@didntduck.org>,
       "lkml" <linux-kernel@vger.kernel.org>, "Andrew Morton" <akpm@osdl.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1579
Lines: 38

> > 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...
> 
> The problem is to tell all subsystems to reinitialize the 
> data for possible CPUs (essentially the concept of "possible" 
> CPUs would need to go)  It would need an reaudit of a lot of 
> code. Probably quite some work.

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.

> 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.
Thanks,
--Natalie
  
> My 
> current code uses disabled CPUs as a heuristic, otherwise 
> half of available CPUs and it can be overwritten by the user.
> 
> -Andi
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/