[lkml]   [2018]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries
> > Yes, "should be".  I could understand that the presence of huge
> > nunmbers of -ve dentries could result in undesirable reclaim of
> > pagecache, etc. Triggering oom-killings is very bad, and presumably
> > has the same cause.
> >
> > Before we go and add a large amount of code to do the shrinker's job
> > for it, we should get a full understanding of what's going wrong. Is
> > it because the dentry_lru had a mixture of +ve and -ve dentries?
> > Should we have a separate LRU for -ve dentries? Are we appropriately
> > aging the various dentries? etc.
> >
> > It could be that tuning/fixing the current code will fix whatever
> > problems inspired this patchset.
> What I think is contributing to the problems and could lead to reclaim
> oddities is the internal fragmentation of dentry slab cache. Dentries are
> relatively small, you get 21 per page on my system, so if trivial to
> reclaim negative dentries get mixed with a small amount of unreclaimable
> positive dentries, you can get a lot of pages in dentry slab cache that are
> unreclaimable.

Could we allocate -ve entries from separate slab?

(cesky, pictures)
 \ /
  Last update: 2018-07-15 22:07    [W:0.110 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site