lkml.org 
[lkml]   [2012]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 1/3 v2] slub: prefetch next freelist pointer in __slab_alloc()
    From
    2012/7/5 Eric Dumazet <eric.dumazet@gmail.com>:
    > On Thu, 2012-07-05 at 00:48 +0900, JoonSoo Kim wrote:
    >> 2012/7/5 Eric Dumazet <eric.dumazet@gmail.com>:
    >> > Its the slow path. I am not convinced its useful on real workloads (not
    >> > a benchmark)
    >> >
    >> > I mean, if a workload hits badly slow path, some more important work
    >> > should be done to avoid this at a higher level.
    >> >
    >>
    >> In hackbench test, fast path allocation is about to 93%.
    >> Is it insufficient?
    >
    > 7% is insufficient I am afraid.
    >
    > One prefetch() in the fast path serves 93% of the allocations,
    > so added icache pressure is ok.
    >
    > One prefetch() in slow path serves 7% of the allocations, do you see the
    > difference ?
    >
    > Adding a prefetch() is usually a win when a benchmark uses the path one
    > million times per second.
    >
    > But adding prefetches also increases kernel size and it hurts globally.
    > (Latency of the kernel depends on its size, when cpu caches are cold)
    >

    Okay.
    Thanks for comments which is very helpful to me.


    \
     
     \ /
      Last update: 2012-07-04 19:01    [W:0.023 / U:32.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site