From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Nick Piggin <npiggin@suse.de>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/2] mm: add context argument to shrinker callback
Date: Fri, 23 Apr 2010 11:58:01 +1000 [thread overview]
Message-ID: <20100423015801.GB10390@dastard> (raw)
In-Reply-To: <20100422164247.GA15882@infradead.org>
On Thu, Apr 22, 2010 at 12:42:47PM -0400, Christoph Hellwig wrote:
> On Fri, Apr 23, 2010 at 02:38:01AM +1000, Nick Piggin wrote:
> > I don't understand, it should be implemented like just all the other
> > shrinkers AFAIKS. Like the dcache one that has to shrink multiple
> > superblocks. There is absolutely no requirement for this API change
> > to implement it in XFS.
>
> The dcache shrinker is an example for a complete mess.
Yes, it is, and one that I think we can clean up significantly by
the use of context based shrinkers.
IMO, a better approach to the VFS shrinkers is to leverage the fact
we already have per-sb dentry LRUs and convert the inode cache to a
per-sb LRU as well.
We can then remove the current dependency problems by moving to
a single context based shrinker (i.e. per-sb) to reclaim from the
per-sb dentry LRU, followed by the per-sb inode LRU via a single
shrinker. That is, remove the global scope from them because that is
the cause of the shrinker call-order dependency problems.
Further, if we then add a filesystem callout to the new superblock
shrinker callout, we can handle all the needs of XFS (and other
filesystems) without requiring them to have global filesystem lists
and without introducing new dependencies between registered
shrinkers.
And given that the shrinker currently handles proportioning reclaim
based on the number of objects reported by the cache, it also allows
us to further simplify the dentry cache reclaim by removing all the
proportioning stuff it does right now...
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>
next prev parent reply other threads:[~2010-04-23 1:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-13 0:24 [PATCH 0/2] Context sensitive memory shrinker support Dave Chinner
2010-04-13 0:24 ` [PATCH 1/2] mm: add context argument to shrinker callback Dave Chinner
2010-04-13 8:17 ` KOSAKI Motohiro
2010-04-18 0:15 ` Christoph Hellwig
2010-04-19 14:00 ` Nick Piggin
2010-04-20 0:41 ` Dave Chinner
2010-04-20 8:38 ` Nick Piggin
2010-04-20 10:32 ` Dave Chinner
2010-04-21 8:40 ` Nick Piggin
2010-04-22 16:32 ` Christoph Hellwig
2010-04-22 16:38 ` Nick Piggin
2010-04-22 16:42 ` Christoph Hellwig
2010-04-22 16:57 ` Nick Piggin
2010-04-23 1:58 ` Dave Chinner [this message]
2010-04-28 3:38 ` Dave Chinner
2010-04-28 9:39 ` Avi Kivity
2010-04-28 13:45 ` Dave Chinner
2010-04-13 0:24 ` [PATCH 2/2] xfs: add a shrinker to background inode reclaim Dave Chinner
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=20100423015801.GB10390@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=xfs@oss.sgi.com \
/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