On Tuesday 28 October 2008 22:06, Pekka Enberg wrote: > On Thu, 2008-10-23 at 19:14 +0200, Eric Dumazet wrote: > > [PATCH] slub: slab_alloc() can use prefetchw() > > > > Most kmalloced() areas are initialized/written right after allocation. > > > > prefetchw() gives a hint to cpu saying this cache line is going to be > > *modified*, even if first access is a read. > > > > Some architectures can save some bus transactions, acquiring > > the cache line in an exclusive way instead of shared one. > > > > Same optimization was done in 2005 on SLAB in commit > > 34342e863c3143640c031760140d640a06c6a5f8 > > ([PATCH] mm/slab.c: prefetchw the start of new allocated objects) > > > > Signed-off-by: Eric Dumazet <dada1@xxxxxxxxxxxxx> > > Christoph, I was sort of expecting a NAK/ACK from you before merging > this. I would be nice to have numbers on this but then again I don't see > how this can hurt either. I've seen explicit prefetches hurt quite surprising amount if they're not placed in appropriate places (which includes putting them in places where the object is already in cache, or the processor is in a good position to have speculatively initiated the operation anyway). I'm not saying it's going to be the case here, but it can be really hard to actually tell if it is worthwhile, IMO. For example, some nice CPU local workloads that are often fitting within cache, might have the object already in cache 99.x% of the time here. prefetch may easily slow things down. -- 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
