[lkml]   [1997]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: New dcache not using slab allocator?
    Date (Rogier Wolff) writes:
    > For example suppose there are only 100 dcache entries:
    > 8,16 and 32 byte entries: total 1 page of 32 byte slots.

    Ah, but observe. On my 2.1.47 kernel equipped with dedicated
    "dcache", "dname-16", "dname-32", and "dname-64" caches, I get the

    % cat /proc/slabinfo
    slabinfo - version: 1.0
    dname-64 15 50
    dname-32 528 588
    dname-16 8630 8636
    dentry 9173 9200
    size-512 6 16
    size-256 18 42
    size-128 55 84
    size-64 183 200
    size-32 142 168

    As you can see, during a modest "cvs release .", the number of dcache
    entries isn't hovering around 100. It's grown closer to 10000
    entries, so the space "unwasted" by introducing a "dname-16" cache is
    tremendous, for some applications.

    During low dcache usage, you're quite right: the savings is
    negligible, if any.

    However, in any case, I'm still convinced that isolating the dcache
    stuff in its own set of caches helps on the fragmentation front. The
    number of active dcache entries is constantly swinging back and forth
    from a minimum of 200-300 to a maximum of several thousand, over and
    over again during "normal usage". The potential for fragmentation is
    huge, because these dcache entries have (in some cases, much) longer
    lifetimes than other kernel objects of similar size.

    Stuffing them in their own cache doesn't *solve* this problem, but it
    lowers the high water mark for fragmented pages. With dedicated slab
    caches for dcache entries, the number of pages "poisoned" by
    long-lived dcache information can't exceed the maximum number of pages
    worth of dcache information stored at any point in time. Without
    dedicated slab caches, the kmalloc caches can be "checkerboarded" with
    long-lived dcache objects and short-lived non-dcache objects, and the
    number of potentially "poisonable" pages is increased.

    Kevin <>

     \ /
      Last update: 2005-03-22 13:40    [W:0.038 / U:0.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site