On Wed, Jan 03, 2018 at 01:39:27PM -0600, Christopher Lameter wrote: > I was looking at the inode/dentry reclaim code today and I thought there > is an obvious and easy to implement way to avoid fragmentation by checking > the number of objects in a slab page. > > > Subject: Heuristic for fragmentation prevention for inode and dentry caches > > When freeing dentries and inodes we often get to the situation > that a slab page cannot be freed because there is only a single > object left in that slab page. > > We add a new function to the slab allocators that returns the > number of objects in the same slab page. > > Then the dentry and inode logic can check if such a situation > exits and take measures to try to reclaim that entry sooner. > > In this patch the check if an inode or dentry has been referenced > (and thus should be kept) is skipped if the freeing of the object > would result in the slab page becoming available. > > That will cause overhead in terms of having to re-allocate and > generate the inoden or dentry but in all likelyhood the inode > or dentry will then be allocated in a slab page that already > contains other inodes or dentries. Thus fragmentation is reduced. Please quantify the difference this makes to inode/dentry cache fragmentation, as well as the overhead of the kobjects_left_in_slab_page() check on every referenced inode and dentry we scan. Basically, if we can't reliably produce and quantify inode/dentry cache fragmentation on demand, then we've go no way to evaluate the effect of such heuristics will on cache footprint. I'm happy to run tests to help develop heuristics, but I don't have time to create tests to reproduce cache fragmentation issues myself. IOWs, before we start down this path, we need to create workloads that reproduce inode/dentry cache fragmentation issues.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
