lkml.org 
[lkml]   [2008]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SLUB defrag pull request?
On Thu, 23 Oct 2008, Eric Dumazet wrote:

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

Most architectures actually can do that. Its probably worth to run some
tests with that. Conversion of a cacheline from shared to exclusive can
cost something.

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

Correct.

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

Right.



\
 
 \ /
  Last update: 2008-10-23 18:51    [W:0.102 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site