[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B7CA825.9090309@kernel.org>
Date: Wed, 17 Feb 2010 18:38:29 -0800
From: Yinghai Lu <yinghai@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
CC: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Christoph Lameter <cl@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [PATCH 34/35] x86: use num_processors for possible cpus
On 02/17/2010 05:32 PM, H. Peter Anvin wrote:
> On 02/10/2010 01:20 AM, Yinghai Lu wrote:
>> some systems that have disable cpus entries because same
>> BIOS will support 2 sockets and 4 sockets and more at
>> same time, BIOS just leave some disable entries, but
>> those system do not support cpu hotplug. we don't need
>> treat disabled_cpus as hotplug cpus.
>> so we can make nr_cpu_ids smaller and save more space
>> (pcpu data allocations), and could make some systems run
>> with logical flat instead of physical flat apic mode
>>
>> -v2: change to black list instead
>> -v3: just remove that, and the one use possible_cpus= directly.
>>
>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>
> I'm confused by this one. This would seem to mean that unless you're
> specifying possible_cpus= then you are not treating anything as
> hotpluggable.
>
> This is clearly wrong, and it would appear to go the wrong direction in
> terms of what is safe.
>
> What am I missing here?
per_cpu setup will allocate some mem for every cpu according to possible cpus.
no spec says that we should disable cpus entries in MADT as hotplug cpus.
also how many system that support hotplug cpus there?
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists