linux-kernel - Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the default percpu allocator

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]

Message-ID: <alpine.LFD.2.00.0904011235160.4130@localhost.localdomain>
Date:	Wed, 1 Apr 2009 12:39:46 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Christoph Lameter <cl@...ux.com>, Tejun Heo <tj@...nel.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	rusty@...tcorp.com.au, tglx@...utronix.de, x86@...nel.org,
	linux-kernel@...r.kernel.org, hpa@...or.com,
	Paul Mundt <lethal@...ux-sh.org>, rmk@....linux.org.uk,
	starvik@...s.com, ralf@...ux-mips.org, davem@...emloft.net,
	cooloney@...nel.org, kyle@...artin.ca, matthew@....cx,
	grundler@...isc-linux.org, takata@...ux-m32r.org,
	benh@...nel.crashing.org, rth@...ddle.net,
	ink@...assic.park.msu.ru, heiko.carstens@...ibm.com,
	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the
 default percpu allocator

On Wed, 1 Apr 2009, Ingo Molnar wrote:
>  
> The rest (unannotated variables) is to be assumed "access-rarely" or 
> "we-dont-care", by default. This is actually 95% of the global 
> variables.

I'm not at all convinced that this is a good option.

The thing is, things like "read_mostly" or "access_rarely" may talk about 
how we access those individual variables, but you're missing a _huge_ 
chunk of the puzzle if you ignore the _correlations_ of those accesses 
with accesses to other variables.

The thign is, if you have variables 'a' and 'b', and they are always 
accessed together, then it's probably worth it to put them in the same 
cacheline.

And that is true EVEN IF 'b' is basically read-only, but 'a' is always 
written to. Marking 'a' as read-only or read-mostly is actually a bad 
idea, since the only thing it can ever result in is a bigger cache 
footprint.

The fact that the read-only cacheline has "nicer" behavior is totally 
irrelevant - it's still an extra cacheline that we're accessing. And they 
aren't free, even if read-only cachelines that can be shared across CPU's 
are certainly a lot cheaper than ones that bounce.

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