lkml.org 
[lkml]   [2001]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Q: explicit alignment control for the slab allocator
On Fri, 2 Mar 2001, Manfred Spraul wrote:
> Zitiere Mark Hemment <markhe@veritas.com>:
> > Could be a win on archs with small L1 cache line sizes (16bytes on a
> > 486) - but most modern processors have larger lines.
>
> IIRC cache colouring was introduced for some sun hardware with 2 memory busses:
> one handes (addr%256<128), the other one (addr%256>=128)
>
> If everything is perfectly aligned, the load one one bus was far higher than the
> load on the other bus.

Yes.
High-end Intel PCs have also had interleaved buses for a few years
now. So it is not just for Sun h/w.


> > Hmm, no that note, seen the L1 line size defined for a Pentium IIII?
> > 128 bytes!! (CONFIG_X86_L1_CACHE_SHIFT of 7). That is probably going to
> > waste a lot of space for small objects.
> >
> No, it doesn't:
> HWCACHE_ALIGN means "do not cross a cache line boundary".

Ah, I broke my code!!!!! :(

In my original slab, the code to do "packing" of objects into a single
cache line was #if-def'ed out for SMP to avoid the possibility of
false-sharing between objects. Not a large possibility, but it exists.

> The question is who should decide about the cache colour offset?
>
> a) the slab allocator always chooses the smallest sensible offset (i.e. the
> alignment)
> b) the caller can specify the offset, e.g. if the caller knows that the hot zone
> is large he would use a larger colour offset.

Only the caller knows about the attributes and usage of an object, so
they should be able to request (not demand) the offset/alignment of the
allocator. (OK, they can demand the alignment.)

> Even if the hot zone is larger than the default offset, is there any advantage
> of increasing the colour offset beyond the alignment?
>
> I don't see an advantage.

I do, but like you, I don't have any data to prove my point.
Time to get profiling?

Mark


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

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.249 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site