[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0906301847260.19482@gentwo.org>
Date: Tue, 30 Jun 2009 18:55:55 -0400 (EDT)
From: Christoph Lameter <cl@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
cc: Andrew Morton <akpm@...ux-foundation.org>, tj@...nel.org,
linux-kernel@...r.kernel.org, x86@...nel.org,
linux-arch@...r.kernel.org, andi@...stfloor.org, hpa@...or.com,
tglx@...utronix.de
Subject: Re: [PATCHSET] percpu: generalize first chunk allocators and improve
lpage NUMA support
On Wed, 1 Jul 2009, Ingo Molnar wrote:
> The usecase i'm talking about is to boot a generic,
> many-CPUs-capable kernel in a guest image.
The many-cpu-capable kernel is not the issue. The number of potential cpus
is config information provided by the hardware. In your case the host
system provides the number of possible processors.
> How would you allow that guest to stay on 2 virtual CPUs but still
> be able to hot-plug many other CPUs if the guest context rises above
> its original CPU utilization?
The use case is a guest that needs to add a couple of thousand processors?
That will require lots of memory and special configuration of the guest
environment simulated. Yes that is an extreme case that will require lots
of per cpu memory.
--
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