Re: SLUB defrag pull request?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoph Lameter a écrit :
On Thu, 23 Oct 2008, Eric Dumazet wrote:

At alloc time, I remember I added a prefetchw() call in SLAB in __cache_alloc(),
this could explain some differences between SLUB and SLAB too, since SLAB
gives a hint to processor to warm its cache.

SLUB touches objects by default when allocating. And it does it immediately in slab_alloc() in order to retrieve the pointer to the next object. So there is no point of hinting there right now.


Please note SLUB touches by reading object.

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.


If we go to the pointer arrays then the situation is similar to SLAB where the object is not touched by the allocator. Then the hint would be useful again.

It is usefull right now for ((SLAB_DESTROY_BY_RCU | SLAB_POISON) or ctor caches.

Probably not that important because many objects are very large anyway, and a prefetchw()
of the begining of object is partial.



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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux