On 04-08-08 23:41, Christoph Lameter wrote:
General interested question -- I recently "accidentally" read some of
slub and I believe that it doesn't feature the cache colouring support
that slab did? Is that true, and if so, wasn't it needed/useful?
I don't know why Christoph decided not to implement it. Christoph?
IMHO cache coloring issues seem to be mostly taken care of by newer more
associative cpu caching designs.
I see. Just gathered a bit of data on this (from sandpile.org):
32-byte lines:
P54 : L1 I 8K, 2-Way
D 8K, 2-Way
L2 External
P55 : L1 I 16K, 4-Way
D 16K, 4-Way
L2 External
P2 : L1 I 16K 4-Way
D 16K 4-Way
L2 128K to 2MB 4-Way
P3 : L1 I 16K 4-Way
D 16K 4-Way
L2 128K to 2MB 4-Way or
256K to 2MB 8-Way
64-byte lines:
P4 : L1 I 12K uOP Trace (8-Way, 6 uOP line)
D 8K 4-Way or
16K 8-Way
L2 128K 2-Way or
128K, 256K 4-Way or
512K, 1M, 2M 8-Way
L3 512K 4-Way or
1M to 8M 8-Way or
2M to 16M 16-Way
Core: L1 I 32K 8-Way
D 32K 8-Way
L2 512K 2-Way or
1M 4-Way or
2M 8-Way or
3M 12-Way or
4M 16-Way
K7 : L1 I 64K 2-Way
D 64K 2-Way
L2 512, 1M, 2M 2-Way or
4M, 8M 1-Way or
64K, 256K, 512K 16-Way
K8 : L1 I 64K 2-Way
D 64K 2-Way
L2 128K to 1M 16-Way
The L1 on K7 and K8 especially seems still a bit of worry here.
Note that the SLAB design origin is Solaris (See the paper by Jeff Bonwick in
1994 that is quoted in mm/slab.c). Logic for cache coloring is mostly avoided
today due to the complexity it would introduce. See also
http://en.wikipedia.org/wiki/CPU_cache.
What one could add to support cache coloring in SLUB is a prearrangement of
the order of object allocation order by constructing the initial freelist for
a page in a certain way. See mm/slub.c::new_slab()
<remains silent>
To me, colouring always seemed like a fairly promising thing but I won't
pretend to have any sort of data.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
