lkml.org 
[lkml]   [2010]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Bug #15713] hackbench regression due to commit 9dfc6e68bfe6e
    From
    Date
    On Mon, 2010-04-26 at 13:09 +0300, Pekka Enberg wrote:
    > Hi,
    >
    > On Mon, Apr 26, 2010 at 9:59 AM, Zhang, Yanmin
    > <yanmin_zhang@linux.intel.com> wrote:
    > >>>> I haven't been able to reproduce this either on my Core 2 machine.
    > >>> Mostly, the regression exists on Nehalem machines. I suspect it's related to
    > >>> hyper-threading machine.
    >
    > On 04/26/2010 09:22 AM, Pekka Enberg wrote:
    > >> OK, so does anyone know why hyper-threading would change things for
    > >> the per-CPU allocator?
    >
    > On Mon, Apr 26, 2010 at 1:02 PM, Tejun Heo <tj@kernel.org> wrote:
    > > My wild speculation is that previously the cpu_slub structures of two
    > > neighboring threads ended up on the same cacheline by accident thanks
    > > to the back to back allocation. W/ the percpu allocator, this no
    > > longer would happen as the allocator groups percpu data together
    > > per-cpu.
    >
    > Yanmin, do we see a lot of remote frees for your hackbench run? IIRC,
    > it's the "deactivate_remote_frees" stat when CONFIG_SLAB_STATS is
    > enabled.

    After runing the testing with 2.6.34-rc5:

    #slabinfo -AD
    Name Objects Alloc Free %Fast Fallb O
    skbuff_head_cache 2518 800011810 800009770 95 19 0 1
    kmalloc-512 1101 800009118 800008441 95 19 0 2
    anon_vma_chain 2500 195878 194477 98 13 0 0
    vm_area_struct 2487 160755 158908 97 20 0 1
    anon_vma 2645 88626 87637 99 12 0 0

    [ymzhang@lkp-ne01 ~]$ cat /sys/kernel/slab/skbuff_head_cache/deactivate_remote_frees
    1 C13=1
    [ymzhang@lkp-ne01 ~]$ cat /sys/kernel/slab/kmalloc-512/deactivate_remote_frees
    3 C8=2 C15=1


    After running testing against 2.6.33 kernel:
    #slabinfo -AD
    Name Objects Alloc Free %Fast Fallb O
    kmalloc-1024 961 800011628 800011167 93 1 0 3
    skbuff_head_cache 2518 800012055 800010015 93 1 0 1
    vm_area_struct 2892 162196 159987 97 19 0 1
    names_cache 128 47139 47141 99 97 0 3
    kmalloc-64 3612 40180 37287 99 89 0 0
    Acpi-State 816 36301 36301 99 98 0 0

    I remember with 2.6.34-rc1, the fast alloc/free are close to the one of 2.6.33.




    \
     
     \ /
      Last update: 2010-04-27 03:43    [W:3.757 / U:0.552 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site