linux-kernel - Re: [PATCHSET] percpu: generalize first chunk allocators and improve lpage NUMA support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/