[lkml]   [2001]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Purpose of the mm/slab.c changes

    On Sun, 9 Sep 2001, Alan Cox wrote:
    > > LIFO is obviously superior due to cache re-use.
    > Interersting question however. On SMP without sufficient per CPU slab caches
    > is tht still the case ?

    That _should_ be fairly easily testable by just changing the cpucache
    tuning, which yu can do through /proc. The default parameters look
    reasonable, though.

    Note, however, that as far as the slab is concerned, this issue never
    exists, if only because all the lists are per-CPU. So the only way you can
    get cross-CPU cache behaviour is (a) when the actual _use_ of the slab is
    moved across CPU's and (b) when you have a page that ends up moving from
    one CPU to the other through page allocation when the slab caches run out.

    Case (a) is clearly rather independent of the actual slab allocation
    logic, and depends on the _user_ of the allocation, not on the allocator

    Case (b) implies that the page allocator might also should also find
    per-CPU LIFO queues in front of the actual allocator useful. That might
    certainly be worth-while looking into - although it would also increase
    the risk of fragementation.

    (Doing per-CPU LIFO queues for the actual page allocator would potentially
    make page alloc/de-alloc much faster due to lower locking requirements
    too. So you might have a double performance win if anybody wants to try
    this out).


    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.023 / U:71.784 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site