From: Dave Chinner <david@fromorbit.com>
To: Christopher Lameter <cl@linux.com>
Cc: Dave Chinner <dchinner@redhat.com>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>,
Christoph Hellwig <hch@lst.de>, Mel Gorman <mel@skynet.ie>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [RFC] Heuristic for inode/dentry fragmentation prevention
Date: Thu, 4 Jan 2018 11:08:56 +1100 [thread overview]
Message-ID: <20180104000856.GA32627@dastard> (raw)
In-Reply-To: <alpine.DEB.2.20.1801031332230.10522@nuc-kabylake>
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@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2018-01-04 0:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-03 19:39 Christopher Lameter
2018-01-03 20:33 ` Matthew Wilcox
2018-01-03 21:06 ` Matthew Wilcox
2018-01-04 0:08 ` Dave Chinner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180104000856.GA32627@dastard \
--to=david@fromorbit.com \
--cc=cl@linux.com \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@skynet.ie \
--cc=penberg@cs.helsinki.fi \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox