[lkml]   [2005]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: VM balancing issues on 2.6.13: dentry cache not getting shrunk enough
    On Wed, Sep 14, 2005 at 06:57:56AM -0700, Martin J. Bligh wrote:
    > >> > Second is Sonny Rao's rbtree dentry reclaim patch which is an attempt
    > >> > to improve this dcache fragmentation problem.
    > >>
    > >> FYI, in the past I've tried this patch to reduce dcache fragmentation on
    > >> an Altix (16k pages, 62 dentries to a slab page) under heavy
    > >> fileserver workloads and it had no measurable effect. It appeared
    > >> that there was almost always at least one active dentry on each page
    > >> in the slab. The story may very well be different on 4k page
    > >> machines, however.
    > >
    > > I always thought dentry freeing would work much better if it
    > > was turned upside down.
    > >
    > > Instead of starting from the high level dcache lists it could
    > > be driven by slab: on memory pressure slab tries to return pages with unused
    > > cache objects. In that case it should check if there are only
    > > a small number of pinned objects on the page set left, and if
    > > yes use a new callback to the higher level user (=dcache) and ask them
    > > to free the object.
    > >
    > > The slab datastructures are not completely suited for this right now,
    > > but it could be done by using one more of the list_heads in struct page
    > > for slab backing pages.
    > >
    > > It would probably not be very LRU but a simple hack of having slowly
    > > increasing dcache generations. Each dentry use updates the generation.
    > > First slab memory freeing pass only frees objects with older generations.
    > If they're freeable, we should easily be able to move them, and therefore
    > compact a fragmented slab. That way we can preserve the LRU'ness of it.
    > Stage 1: free the oldest entries. Stage 2: compact the slab into whole
    > pages. Stage 3: free whole pages back to teh page allocator.
    > > Using slowly increasing generations has the advantage of timestamps
    > > that you can avoid dirtying cache lines in the common case when
    > > the generation doesn't change on access (= no additional cache line bouncing)
    > > and it would easily allow to tune the aging rate under stress by changing the
    > > length of the generation.
    > LRU algorithm may need general tweaking like this anyway ... strict LRU
    > is expensive to keep.

    Based on what I remember, I'd contend it isn't really LRU today, so I
    wouldn't try and stick to something that we aren't doing. :)
    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-09-14 17:46    [W:0.023 / U:0.940 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site