Re: SLUB defrag pull request? - Kernel

This is a discussion on Re: SLUB defrag pull request? - Kernel ; 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 ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 47 of 47

Thread: Re: SLUB defrag pull request?

  1. Re: SLUB defrag pull request?

    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.

    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.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: SLUB defrag pull request?

    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-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: 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.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: SLUB defrag pull request?

    Christoph Lameter a écrit :
    > 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.
    >


    Please check following patch as a followup

    [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


    diff --git a/mm/slub.c b/mm/slub.c
    index 0c83e6a..c2017a3 100644
    --- a/mm/slub.c
    +++ b/mm/slub.c
    @@ -1592,13 +1592,14 @@ static __always_inline void *slab_alloc(struct kmem_cache *s,

    local_irq_save(flags);
    c = get_cpu_slab(s, smp_processor_id());
    + object = c->freelist;
    + prefetchw(object);
    objsize = c->objsize;
    - if (unlikely(!c->freelist || !node_match(c, node)))
    + if (unlikely(!object || !node_match(c, node)))

    object = __slab_alloc(s, gfpflags, node, addr, c);

    else {
    - object = c->freelist;
    c->freelist = object[c->offset];
    stat(c, ALLOC_FASTPATH);
    }


  5. Re: SLUB defrag pull request?

    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


    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.

    Pekka

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: SLUB defrag pull request?

    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

    >
    > 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-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: SLUB defrag pull request?

    On Tue, 28 Oct 2008, Pekka Enberg wrote:

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


    Its an additional instruction in a hot path. Lets see some numbers first.

    Try tbench. Seems to be very popular recently. Or my microbenchmarks
    for slab allocations on kernel.org.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3