> Hello folks,
>
> I remember some months ago, someone stated that he working on
> L2 page coloring (Wasn't it Mr. "SLAB" Hemment ?).
>
> Is there anything usable already? And has anyone some
> interesting pointers to this theme (A friend has to write
> about it)?
The current slab cache (mm/slab.c) implement cache colouring. A description
can be found in Jeff Bonwick's "The Slab Allocator" paper (from Usenix I
think). It gives quite a speedup for some things, e.g. the 2.1 Fastrouting
option works about 10% faster with slabified skbuff headers.
Implementing page colouring into the underlying buddy page allocator
was tried, but given up because it actually slowed down some things and
leads to bad fragmentation [it is probably required to replace the simply
and fast buddy allocator with a more sophisticated zone allocator to
prevent fragmentation].
Unfortunately this is very bad for the Linux MIPS port for CPUs who
have a virtually indexed cache. Without page colouring there will be lots
of cache line aliases [two cache lines which point to the same physical
memory address], and they're rather slow to handle in software, especially
on older MIPS chips.
Generally: page colouring gives speed, but causes more memory fragmentation,
so it is not always a win. For example the current Linux 2.1 NFS has bad
problems to deal with big read/write sizes. This is partly caused by the
slab allocator's colouring. In order to do the colouring properly it has
to grab big memory areas from the page allocator. When allocating big slab
objects [e.g. to reassemble a 6K fragment the network stack grabs a 6K SK buff,
and the slab kmalloc emulation rounds that to 8K] the slab allocator requests
big pages to have some room "to work with". This leads to the infamous
"cannot get free page" messages.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu