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:	Wed, 01 Jul 2009 09:48:15 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	linux-arch@...r.kernel.org, hpa@...or.com, tglx@...utronix.de
Subject: Re: [PATCHSET] percpu: generalize first chunk allocators and improve
 lpage NUMA support

Hello, Andi.

Andi Kleen wrote:
>> 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?
> 
> (unless you're planning to rewrite lots of possible cpu users all over
> the tree) -- the only way is to keep the percpu area small and preallocate. 
> 
> As long as the per cpu data size stays reasonable (not more than a 100-200k)
> that's very doable. It probably won't work with 4096 guest CPUs without
> wasting too much memory, but then I don't think we have any Hypervisor
> that scales to that many CPUs anyways, so it's not the biggest
> concern. For the 128CPU case it works (although i might need
> to enlarge vmalloc area a bit on 32bit) 

I don't see much reason why we should put artificial limit on how much
percpu memory could be used.  For lockdep, that much of percpu memory
is actually necessary.  Another layer of indirection surely can lessen
the pressure on the generic percpu implementation but the problem can
be solved by the generic code without too much difficulty.

Thanks.

-- 
tejun
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ