From: Dave Chinner <david@fromorbit.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 0/5] Per-superblock shrinkers
Date: Mon, 17 May 2010 10:19:26 +1000 [thread overview]
Message-ID: <20100517001926.GI8120@dastard> (raw)
In-Reply-To: <20100515013005.GA31073@ZenIV.linux.org.uk>
On Sat, May 15, 2010 at 02:30:05AM +0100, Al Viro wrote:
> On Fri, May 14, 2010 at 05:24:18PM +1000, Dave Chinner wrote:
> >
> > This series reworks the filesystem shrinkers. We currently have a
> > set of issues with the current filesystem shrinkers:
> >
> > 1. There is an dependency between dentry and inode cache
> > shrinking that is only implicitly defined by the order of
> > shrinker registration.
> > 2. The shrinkers need to walk the superblock list and pin
> > the superblock to avoid unmount races with the sb going
> > away.
> > 3. The dentry cache uses per-superblock LRUs and proportions
> > reclaim between all the superblocks which means we are
> > doing breadth based reclaim. This means we touch every
> > superblock for every shrinker call, and may only reclaim
> > a single dentry at a time from a given superblock.
> > 4. The inode cache has a global LRU, so it has different
> > reclaim patterns to the dentry cache, despite the fact
> > that the dentry cache is generally the only thing that
> > pins inodes in memory.
> > 5. Filesystems need to register their own shrinkers for
> > caches and can't co-ordinate them with the dentry and
> > inode cache shrinkers.
>
> NAK in that form; sb refcounting and iterators had been reworked for .34,
> so at least it needs rediff on top of that.
The tree I based this on was 2.6.34-rc7 - is there new code in a
-next branch somewhere?
> What's more, it's very
> obviously broken wrt locking - you are unregistering a shrinker
> from __put_super(). I.e. grab rwsem exclusively under a spinlock.
> Essentially, you've turned dropping a _passive_ reference to superblock
> (currently an operation safe in any context) into an operation allowed
> only when no fs or vm locks are held by caller. Not going to work...
Yeah, I picked that up after I posted it. My bad - I'll look into how
I can rework that for the next iteration.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 0/5] Per-superblock shrinkers
Date: Mon, 17 May 2010 10:19:26 +1000 [thread overview]
Message-ID: <20100517001926.GI8120@dastard> (raw)
In-Reply-To: <20100515013005.GA31073@ZenIV.linux.org.uk>
On Sat, May 15, 2010 at 02:30:05AM +0100, Al Viro wrote:
> On Fri, May 14, 2010 at 05:24:18PM +1000, Dave Chinner wrote:
> >
> > This series reworks the filesystem shrinkers. We currently have a
> > set of issues with the current filesystem shrinkers:
> >
> > 1. There is an dependency between dentry and inode cache
> > shrinking that is only implicitly defined by the order of
> > shrinker registration.
> > 2. The shrinkers need to walk the superblock list and pin
> > the superblock to avoid unmount races with the sb going
> > away.
> > 3. The dentry cache uses per-superblock LRUs and proportions
> > reclaim between all the superblocks which means we are
> > doing breadth based reclaim. This means we touch every
> > superblock for every shrinker call, and may only reclaim
> > a single dentry at a time from a given superblock.
> > 4. The inode cache has a global LRU, so it has different
> > reclaim patterns to the dentry cache, despite the fact
> > that the dentry cache is generally the only thing that
> > pins inodes in memory.
> > 5. Filesystems need to register their own shrinkers for
> > caches and can't co-ordinate them with the dentry and
> > inode cache shrinkers.
>
> NAK in that form; sb refcounting and iterators had been reworked for .34,
> so at least it needs rediff on top of that.
The tree I based this on was 2.6.34-rc7 - is there new code in a
-next branch somewhere?
> What's more, it's very
> obviously broken wrt locking - you are unregistering a shrinker
> from __put_super(). I.e. grab rwsem exclusively under a spinlock.
> Essentially, you've turned dropping a _passive_ reference to superblock
> (currently an operation safe in any context) into an operation allowed
> only when no fs or vm locks are held by caller. Not going to work...
Yeah, I picked that up after I posted it. My bad - I'll look into how
I can rework that for the next iteration.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 0/5] Per-superblock shrinkers
Date: Mon, 17 May 2010 10:19:26 +1000 [thread overview]
Message-ID: <20100517001926.GI8120@dastard> (raw)
In-Reply-To: <20100515013005.GA31073@ZenIV.linux.org.uk>
On Sat, May 15, 2010 at 02:30:05AM +0100, Al Viro wrote:
> On Fri, May 14, 2010 at 05:24:18PM +1000, Dave Chinner wrote:
> >
> > This series reworks the filesystem shrinkers. We currently have a
> > set of issues with the current filesystem shrinkers:
> >
> > 1. There is an dependency between dentry and inode cache
> > shrinking that is only implicitly defined by the order of
> > shrinker registration.
> > 2. The shrinkers need to walk the superblock list and pin
> > the superblock to avoid unmount races with the sb going
> > away.
> > 3. The dentry cache uses per-superblock LRUs and proportions
> > reclaim between all the superblocks which means we are
> > doing breadth based reclaim. This means we touch every
> > superblock for every shrinker call, and may only reclaim
> > a single dentry at a time from a given superblock.
> > 4. The inode cache has a global LRU, so it has different
> > reclaim patterns to the dentry cache, despite the fact
> > that the dentry cache is generally the only thing that
> > pins inodes in memory.
> > 5. Filesystems need to register their own shrinkers for
> > caches and can't co-ordinate them with the dentry and
> > inode cache shrinkers.
>
> NAK in that form; sb refcounting and iterators had been reworked for .34,
> so at least it needs rediff on top of that.
The tree I based this on was 2.6.34-rc7 - is there new code in a
-next branch somewhere?
> What's more, it's very
> obviously broken wrt locking - you are unregistering a shrinker
> from __put_super(). I.e. grab rwsem exclusively under a spinlock.
> Essentially, you've turned dropping a _passive_ reference to superblock
> (currently an operation safe in any context) into an operation allowed
> only when no fs or vm locks are held by caller. Not going to work...
Yeah, I picked that up after I posted it. My bad - I'll look into how
I can rework that for the next iteration.
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-05-17 0:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-14 7:24 [PATCH 0/5] Per-superblock shrinkers Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` [PATCH 1/5] inode: Make unused inode LRU per superblock Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` [PATCH 2/5] mm: add context argument to shrinker callback Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` [PATCH 3/5] superblock: introduce per-sb cache shrinker infrastructure Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` [PATCH 4/5] superblock: add filesystem shrinker operations Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` [PATCH 5/5] xfs: make use of new shrinker callout Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 7:24 ` Dave Chinner
2010-05-14 17:46 ` Defrag in shrinkers (was Re: [PATCH 0/5] Per-superblock shrinkers) Christoph Lameter
2010-05-14 17:46 ` Christoph Lameter
2010-05-14 17:46 ` Christoph Lameter
2010-05-14 20:36 ` Defrag in shrinkers Andi Kleen
2010-05-14 20:36 ` Andi Kleen
2010-05-14 20:36 ` Andi Kleen
2010-05-15 17:08 ` Ed Tomlinson
2010-05-15 17:08 ` Ed Tomlinson
2010-05-15 17:08 ` Ed Tomlinson
2010-05-17 0:24 ` Dave Chinner
2010-05-17 0:24 ` Dave Chinner
2010-05-17 0:24 ` Dave Chinner
2010-05-15 1:15 ` Defrag in shrinkers (was Re: [PATCH 0/5] Per-superblock shrinkers) Dave Chinner
2010-05-15 1:15 ` Dave Chinner
2010-05-15 1:15 ` Dave Chinner
2010-05-15 1:30 ` [PATCH 0/5] Per-superblock shrinkers Al Viro
2010-05-15 1:30 ` Al Viro
2010-05-15 1:30 ` Al Viro
2010-05-17 0:19 ` Dave Chinner [this message]
2010-05-17 0:19 ` Dave Chinner
2010-05-17 0:19 ` 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=20100517001926.GI8120@dastard \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=viro@ZenIV.linux.org.uk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.