Re: [uml-devel] Re: [PATCH 4/6] x86_64: fix L1_CACHE_SHIFT_MAX for Intel EM64T [for 2.6.14?]

Blaisorblade
2005-10-25T23:56:16Z

On Wednesday 26 October 2005 01:33, Andi Kleen wrote:
> On Wednesday 26 October 2005 00:44, Blaisorblade wrote:
> > For what I see, that's based on the tradeoff between space and contention
> > - for instance there are few zones only, so there's no big waste.

> If space is precious it shouldn't be padded at all.
Ah, when the structure has many instances padding should be reduced, you mean.
But well, I think slab itself adds some padding to separate instances, for
this effect and for cache colouring (I guess that means to prevent too many
different things from being allocated on addresses matching on the low-order
bits, so that inserting one in the cache means evicting another of the two -
it's something I guessed when I studied set-associative caches).

> > In practice, interpreting !X86_GENERIC as "I will run this kernel on
> > _this_ processor" could also be done.
>
> That is what it always meant yes.
>
> > However, in case you didn't note, max_align is never enough on EM64T
> > currently, right?
>
> I will prepare patches for .15 to remove it completely, that should fix
> that problem.
Making L1_CACHE_SHIFT_MAX and L1_CACHE_SHIFT match, right? Or forcing all
architectures to support something like X86_GENERIC?

Also,

#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)

should probably be made general, while at it.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

___________________________________
Yahoo! Messenger: chiamate gratuite in tutto il mondo