On Mon, 8 Sep 2008, Andi Kleen wrote:
quoted text
>
> Originally it was an option because the 128 byte cache line it selects
> caused bloat in several important data structures. That was back
> then when cache line padded NR_CPUs arrays were still pretty common.
> I don't know if it's still a problem, but before making it default y
> it would be good to check the dynamic+static memory cost at least.

Btw, I do think that the whole NOPL issue is separate from all the other 
issues. There can be _other_ cases where it really is worth doing some 
"generic" optimizations or being more "specific", and my argument really 
is that NOPL is _not_ one of those cases.

So I'm still not sure that X86_GENERIC is necessarily the answer. The 
answer may be:

 - never use NOPL statically unless we _know_ it works (eg x86-64)

 - never allow such a stupid decision by gcc as to use NOPL on x86-32.

..and then leave X86_GENERIC alone wrt everything else.

Peter - does gcc actually use NOPL in _32-bit_ code too? It really seems 
to be a stupid decision to make a binary not run on other CPU's over 
something as trivial as that. That's something I'd expect out of an Intel 
compiler just to mess with AMD, not out of gcc.

			Linus
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/