Re: [RFC] Heuristic for inode/dentry fragmentation prevention

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux