linux-kernel - Re: [PATCH] x86: eliminate redundant/contradicting cache line size config options

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: <20091123100935.GB3724@elte.hu>
Date:	Mon, 23 Nov 2009 11:09:35 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Jan Beulich <JBeulich@...ell.com>, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, hpa@...or.com,
	Ravikiran Thirumalai <kiran@...lex86.org>,
	Shai Fultheim <shai@...lemp.com>
Subject: Re: [PATCH] x86: eliminate redundant/contradicting cache line size
 config options


* Nick Piggin <npiggin@...e.de> wrote:

> On Mon, Nov 23, 2009 at 09:34:59AM +0100, Ingo Molnar wrote:
> > 
> > * Arjan van de Ven <arjan@...radead.org> wrote:
> > 
> > > On Thu, 19 Nov 2009 09:13:07 +0100
> > > Nick Piggin <npiggin@...e.de> wrote:
> > > > 
> > > > My other point was just this, but I don't care too much. But it is
> > > > worded pretty negatively. The key here is that increasing the value
> > > > too large tends to only cost a very small amount of size (and no
> > > > increase in cacheline foot print, only RAM). 
> > > 
> > > 128 has a pretty significant impact on TPC-C benchmarks.....
> > > it was the top issue until mainline fixed it to default to 64
> > 
> > Mind sending a patch that sets the default to 64 on NUMA too?
> 
> This is what I mean. It should all be the same value, and that
> value should depend on the architectures to support (rather than
> NUMA or something like that). With the internode simply being
> the exception for the exceptional vSMP architecture.
> 
>  
> > P4 based NUMA boxes are ... a bad memory to be forgotten.
> 
> I still think it would make sense to do this via Kconfig rather than 
> implicitly saying that we don't care about P4s even if the user has 
> apparently wanted to support them.

That was what i meant. Right now if P4 is set in the .config we'll use a 
cache-shift of 7 - i.e. 128 byte cacheline size.

What we want is to remove that NUMA dependent quirk - it doesnt make 
sense.

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