From: Andi Kleen <ak@suse.de>
To: Natalie.Protasevich@unisys.com
Cc: shaohua.li@intel.com, zwane@arm.linux.org.uk,
ashok.raj@intel.com, akpm@osdl.org,
lhcs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
hotplug_sig@lists.osdl.org
Subject: Re: [patch 1/1] Hot plug CPU to support physical add of new processors (i386)
Date: Thu, 1 Sep 2005 10:45:10 +0200 [thread overview]
Message-ID: <200509011045.11142.ak@suse.de> (raw)
In-Reply-To: <20050831121311.5FC7C57D99@linux.site>
Hallo Natalie,
On Wednesday 31 August 2005 14:13, Natalie.Protasevich@unisys.com wrote:
> Current IA32 CPU hotplug code doesn't allow bringing up processors that
> were not present in the boot configuration. To make existing hot plug
> facility more practical for physical hot plug, possible processors should
> be encountered during boot for potentual hot add/replace/remove. On ES7000,
> ACPI marks all the sockets that are empty or not assigned to the
> partitionas as "disabled".
Good idea. In fact I always hated the behaviour of the existing
hotplug code that assumes all possible CPUs can be hotplugged.
It would be much nicer to be told be the firmware what CPUs
are hotpluggable. It would be great if all ia32/x86-64 hotplug capable
BIOS behaved like your.
> struct warm_boot_cpu_info info;
> struct work_struct task;
> int apicid, ret;
> + extern u8 bios_cpu_apicid[NR_CPUS];
This should be in some header.
>
> lock_cpu_hotplug();
> - apicid = x86_cpu_to_apicid[cpu];
> + apicid = bios_cpu_apicid[cpu];
Why this change? It seems unrelated.
> if (apicid == BAD_APICID) {
> ret = -ENODEV;
> goto exit;
> diff -puN arch/i386/mach-default/topology.c~hotcpu-i386
> arch/i386/mach-default/topology.c ---
> linux-2.6.13-rc6-mm2/arch/i386/mach-default/topology.c~hotcpu-i386 2005-08-
>31 04:17:20.957019600 -0700 +++
> linux-2.6.13-rc6-mm2-root/arch/i386/mach-default/topology.c 2005-08-31
> 04:22:13.020619184 -0700 @@ -76,7 +76,7 @@ static int __init
> topology_init(void)
> for_each_online_node(i)
> arch_register_node(i);
>
> - for_each_present_cpu(i)
> + for_each_cpu(i)
This looks wrong. The CPUs should be in the present mask
if it's present. Followup code similar.
BTW shouldn't there be some attribute in sysfs that says
"CPU disabled"?
-Andi
next prev parent reply other threads:[~2005-09-01 8:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-31 12:13 [patch 1/1] Hot plug CPU to support physical add of new processors (i386) Natalie.Protasevich
2005-09-01 8:00 ` Shaohua Li
2005-09-01 8:45 ` Andi Kleen [this message]
2005-09-01 17:53 ` Ashok Raj
2005-09-01 15:30 ` [Hotplug_sig] " Nathan Lynch
2005-09-01 17:36 ` Ashok Raj
-- strict thread matches above, loose matches on Subject: below --
2005-09-01 13:43 Protasevich, Natalie
2005-09-01 21:09 Protasevich, Natalie
2005-09-01 21:26 ` Ashok Raj
2005-09-01 22:56 Protasevich, Natalie
2005-09-20 23:57 Natalie.Protasevich
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=200509011045.11142.ak@suse.de \
--to=ak@suse.de \
--cc=Natalie.Protasevich@unisys.com \
--cc=akpm@osdl.org \
--cc=ashok.raj@intel.com \
--cc=hotplug_sig@lists.osdl.org \
--cc=lhcs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
--cc=zwane@arm.linux.org.uk \
/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