linux-kernel - Re: [PATCH 34/35] x86: use num

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 19 Feb 2010 08:14:55 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	Yinghai Lu <yinghai@...nel.org>, 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>,
	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/19/2010 07:14 AM, Christoph Lameter wrote:
> On Thu, 18 Feb 2010, H. Peter Anvin wrote:
> 
>>> As I have also repeatedly stated: Dynamic percpu data allocation when
>>> onlining / offlining processors will complicate locking (cannot rely on
>>> percpu be present anymore) and introduce numerous additional
>>> hotplug notifiers into subsystems.
>>
>> I did state explicitly "on first up".  Trying to free it would be
>> insane.  There are a couple of subsystems which are percpu memory
>> pigs... so far it's not clear any of them actually matters in a
>> production kernel.  60K * 16 phantom processors is still ~ 1 MB, which
>> probably isn't enough to worry about but isn't great.
> 
> The first up still means the addition of notifiers for subsystems that
> have to initialilze their per cpu data and dealing with potential races
> that would be caused by adding those.
> 

Yes... it's ugly no matter which way we go (wasted memory vs. code
complexity.)  Wasted memory can be alleviated by minimizing the use of
percpu memory; callbacks can be minimized by keeping a pattern buffer to
which new allocations are initialized, and encouraging users to set
things up so that that state is at least initially sufficient.

We're probably okay for now (the only really heavy users of percpu are
debugging at this point), and the other thing that might be worthwhile
is if we can actually determine what platforms a "disabled CPU" could
actually come to life.  Hopefully disabled CPUs that aren't really
available aren't *all* that common (it's not too common that people even
turn off SMT, and if they know to do that they might be willing to add a
kernel option if they care about the memory, too.)

However, if percpu memory usage increases, it might be messy.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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