[lkml]   [2001]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectPurpose of the mm/slab.c changes
    What's the purpose of the mm/slab.c changes?

    Linus, Alan, could you please drop them. Switching from 1 list to 3
    lists is just a slowdown.

    2.4.9 2.4.9-ac9
    km(1) 0x87 0x89
    kf(1) 0xa9 0xa8
    kf(cachep, 1) 0xad 0xad
    km(4096) 0x7B 0x87 (+24% without overhead!)
    kf(4096) 0xcB 0xd1
    kf(cachep,4096) 0xcc 0xd3

    (cpu ticks on a Duron 700, UP kernel, 100 calls in a tight loop, loop
    overhead (0x49) not removed)

    Benchmarking with SMP kernel is meaningless, since the actual list
    changes are outside of the hot path - I did it, and the differences are
    negligable (+-1 cpu tick)

    And this is a benchmark with 100 calls in a tight loop - Andrea's patch
    adds several additional branches, in real-world there would be an even
    larger slowdown.

    If there are real performance problems with the slab, then the not-yet
    optimized parts should get changed:

    * kmalloc(): the loop to find the correct slab is too slow. (the numbers
    in the table are without the loop, i.e.
    kmem_cache_alloc(kmem_find_general_cache(4096, SLAB_KERNEL),

    * finetune the size of the per-cpu caches
    * finetune the amount of pages freed during kmem_cache_reap()
    * replace the division in kmem_cache_free_one() with a multiplication.
    (UP only, on SMP outside of the hot path)
    * enable OPTIMIZE - could help on platforms without a fast
    virt_addr->struct page lookup.

    I have a patch with some optimization, but I tought that would be 2.5


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:03    [W:0.022 / U:1.952 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site