From: Nick Piggin <npiggin@suse.de>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
xfs@oss.sgi.com, Al Viro <viro@ZenIV.linux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5 v2] superblock: introduce per-sb cache shrinker infrastructure
Date: Thu, 27 May 2010 16:46:31 +1000 [thread overview]
Message-ID: <20100527064631.GK22536@laptop> (raw)
In-Reply-To: <20100527061751.GK12087@dastard>
On Thu, May 27, 2010 at 04:17:51PM +1000, Dave Chinner wrote:
> On Thu, May 27, 2010 at 05:01:20AM +0100, Al Viro wrote:
> > Um... Maybe I'm dumb, but what's wrong with doing unregistration from
> > deactivate_locked_super(), right after the call of ->kill_sb()? At that
> > point ->s_umount is already dropped, so we won't deadlock at all.
> > Shrinker rwsem will make sure that all shrinkers-in-progress will run
> > to completion, so we won't get a superblock freed under prune_super().
> > I don't particulary mind down_try_read() in prune_super(), but why not
> > make life obviously safer?
> >
> > Am I missing something here?
>
> I was worried about memory allocation in the ->kill_sb path
> deadlocking on the s_umount lock if it enters reclaim. e.g. XFS
> inodes can still be dirty even after the VFS has disposed of them,
> and writing them back can require page cache allocation for the
> backing buffers. If allocation recurses back into the shrinker, we
> can deadlock on the s_umount lock. This doesn't seem like an XFS
> specific problem, so I used a trylock to avoid that whole class of
> problems (same way the current shrinkers do).
If GFP_FS is set, we wouldn't touch the locks. It is a concern
though, if __GFP_FS allocations were previously permitted under
the exclusive lock.
> >From there, we can unregister the shrinker before calling ->kill_sb
> as per above. That, in turn, means that the unmount
> invalidate_inodes() vs shrinker race goes away and the iprune_sem is
> not needed in the new prune_icache_sb() function. I'm pretty sure
> that I can now remove the iprune_sem, but I haven't written the
> patch to do that yet.
I do really like that aspect of your patch. It's nice to have the
shrinker always only operating against active supers. So I would
be in favour of your current scheme.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, xfs@oss.sgi.com
Subject: Re: [PATCH 3/5 v2] superblock: introduce per-sb cache shrinker infrastructure
Date: Thu, 27 May 2010 16:46:31 +1000 [thread overview]
Message-ID: <20100527064631.GK22536@laptop> (raw)
In-Reply-To: <20100527061751.GK12087@dastard>
On Thu, May 27, 2010 at 04:17:51PM +1000, Dave Chinner wrote:
> On Thu, May 27, 2010 at 05:01:20AM +0100, Al Viro wrote:
> > Um... Maybe I'm dumb, but what's wrong with doing unregistration from
> > deactivate_locked_super(), right after the call of ->kill_sb()? At that
> > point ->s_umount is already dropped, so we won't deadlock at all.
> > Shrinker rwsem will make sure that all shrinkers-in-progress will run
> > to completion, so we won't get a superblock freed under prune_super().
> > I don't particulary mind down_try_read() in prune_super(), but why not
> > make life obviously safer?
> >
> > Am I missing something here?
>
> I was worried about memory allocation in the ->kill_sb path
> deadlocking on the s_umount lock if it enters reclaim. e.g. XFS
> inodes can still be dirty even after the VFS has disposed of them,
> and writing them back can require page cache allocation for the
> backing buffers. If allocation recurses back into the shrinker, we
> can deadlock on the s_umount lock. This doesn't seem like an XFS
> specific problem, so I used a trylock to avoid that whole class of
> problems (same way the current shrinkers do).
If GFP_FS is set, we wouldn't touch the locks. It is a concern
though, if __GFP_FS allocations were previously permitted under
the exclusive lock.
> >From there, we can unregister the shrinker before calling ->kill_sb
> as per above. That, in turn, means that the unmount
> invalidate_inodes() vs shrinker race goes away and the iprune_sem is
> not needed in the new prune_icache_sb() function. I'm pretty sure
> that I can now remove the iprune_sem, but I haven't written the
> patch to do that yet.
I do really like that aspect of your patch. It's nice to have the
shrinker always only operating against active supers. So I would
be in favour of your current scheme.
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, xfs@oss.sgi.com
Subject: Re: [PATCH 3/5 v2] superblock: introduce per-sb cache shrinker infrastructure
Date: Thu, 27 May 2010 16:46:31 +1000 [thread overview]
Message-ID: <20100527064631.GK22536@laptop> (raw)
In-Reply-To: <20100527061751.GK12087@dastard>
On Thu, May 27, 2010 at 04:17:51PM +1000, Dave Chinner wrote:
> On Thu, May 27, 2010 at 05:01:20AM +0100, Al Viro wrote:
> > Um... Maybe I'm dumb, but what's wrong with doing unregistration from
> > deactivate_locked_super(), right after the call of ->kill_sb()? At that
> > point ->s_umount is already dropped, so we won't deadlock at all.
> > Shrinker rwsem will make sure that all shrinkers-in-progress will run
> > to completion, so we won't get a superblock freed under prune_super().
> > I don't particulary mind down_try_read() in prune_super(), but why not
> > make life obviously safer?
> >
> > Am I missing something here?
>
> I was worried about memory allocation in the ->kill_sb path
> deadlocking on the s_umount lock if it enters reclaim. e.g. XFS
> inodes can still be dirty even after the VFS has disposed of them,
> and writing them back can require page cache allocation for the
> backing buffers. If allocation recurses back into the shrinker, we
> can deadlock on the s_umount lock. This doesn't seem like an XFS
> specific problem, so I used a trylock to avoid that whole class of
> problems (same way the current shrinkers do).
If GFP_FS is set, we wouldn't touch the locks. It is a concern
though, if __GFP_FS allocations were previously permitted under
the exclusive lock.
> >From there, we can unregister the shrinker before calling ->kill_sb
> as per above. That, in turn, means that the unmount
> invalidate_inodes() vs shrinker race goes away and the iprune_sem is
> not needed in the new prune_icache_sb() function. I'm pretty sure
> that I can now remove the iprune_sem, but I haven't written the
> patch to do that yet.
I do really like that aspect of your patch. It's nice to have the
shrinker always only operating against active supers. So I would
be in favour of your current scheme.
--
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-27 6:44 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-25 8:53 [PATCH 0/5] Per superblock shrinkers V2 Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` [PATCH 1/5] inode: Make unused inode LRU per superblock Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-26 16:17 ` Nick Piggin
2010-05-26 16:17 ` Nick Piggin
2010-05-26 16:17 ` Nick Piggin
2010-05-26 23:01 ` Dave Chinner
2010-05-26 23:01 ` Dave Chinner
2010-05-26 23:01 ` Dave Chinner
2010-05-26 23:01 ` Dave Chinner
2010-05-27 2:04 ` Nick Piggin
2010-05-27 2:04 ` Nick Piggin
2010-05-27 2:04 ` Nick Piggin
2010-05-27 2:04 ` Nick Piggin
2010-05-27 4:02 ` Dave Chinner
2010-05-27 4:02 ` Dave Chinner
2010-05-27 4:02 ` Dave Chinner
2010-05-27 4:02 ` Dave Chinner
2010-05-27 4:23 ` Nick Piggin
2010-05-27 4:23 ` Nick Piggin
2010-05-27 4:23 ` Nick Piggin
2010-05-27 4:23 ` Nick Piggin
2010-05-27 20:32 ` Andrew Morton
2010-05-27 20:32 ` Andrew Morton
2010-05-27 20:32 ` Andrew Morton
2010-05-27 22:54 ` Dave Chinner
2010-05-27 22:54 ` Dave Chinner
2010-05-27 22:54 ` Dave Chinner
2010-05-28 10:07 ` Nick Piggin
2010-05-28 10:07 ` Nick Piggin
2010-05-28 10:07 ` Nick Piggin
2010-05-25 8:53 ` [PATCH 2/5] mm: add context argument to shrinker callback Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` [PATCH 3/5] superblock: introduce per-sb cache shrinker infrastructure Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-26 16:41 ` Nick Piggin
2010-05-26 16:41 ` Nick Piggin
2010-05-26 16:41 ` Nick Piggin
2010-05-26 16:41 ` Nick Piggin
2010-05-26 23:12 ` Dave Chinner
2010-05-26 23:12 ` Dave Chinner
2010-05-26 23:12 ` Dave Chinner
2010-05-26 23:12 ` Dave Chinner
2010-05-27 1:53 ` [PATCH 3/5 v2] " Dave Chinner
2010-05-27 1:53 ` Dave Chinner
2010-05-27 1:53 ` Dave Chinner
2010-05-27 4:01 ` Al Viro
2010-05-27 4:01 ` Al Viro
2010-05-27 4:01 ` Al Viro
2010-05-27 6:17 ` Dave Chinner
2010-05-27 6:17 ` Dave Chinner
2010-05-27 6:17 ` Dave Chinner
2010-05-27 6:46 ` Nick Piggin [this message]
2010-05-27 6:46 ` Nick Piggin
2010-05-27 6:46 ` Nick Piggin
2010-05-27 2:19 ` [PATCH 3/5] " Nick Piggin
2010-05-27 2:19 ` Nick Piggin
2010-05-27 2:19 ` Nick Piggin
2010-05-27 2:19 ` Nick Piggin
2010-05-27 4:07 ` Dave Chinner
2010-05-27 4:07 ` Dave Chinner
2010-05-27 4:07 ` Dave Chinner
2010-05-27 4:24 ` Nick Piggin
2010-05-27 4:24 ` Nick Piggin
2010-05-27 4:24 ` Nick Piggin
2010-05-27 6:35 ` Nick Piggin
2010-05-27 6:35 ` Nick Piggin
2010-05-27 6:35 ` Nick Piggin
2010-05-27 6:35 ` Nick Piggin
2010-05-27 22:40 ` Dave Chinner
2010-05-27 22:40 ` Dave Chinner
2010-05-27 22:40 ` Dave Chinner
2010-05-27 22:40 ` Dave Chinner
2010-05-28 5:19 ` Nick Piggin
2010-05-28 5:19 ` Nick Piggin
2010-05-28 5:19 ` Nick Piggin
2010-05-28 5:19 ` Nick Piggin
2010-05-31 6:39 ` Dave Chinner
2010-05-31 6:39 ` Dave Chinner
2010-05-31 6:39 ` Dave Chinner
2010-05-31 6:39 ` Dave Chinner
2010-05-31 7:28 ` Nick Piggin
2010-05-31 7:28 ` Nick Piggin
2010-05-31 7:28 ` Nick Piggin
2010-05-31 7:28 ` Nick Piggin
2010-05-27 20:32 ` Andrew Morton
2010-05-27 20:32 ` Andrew Morton
2010-05-27 20:32 ` Andrew Morton
2010-05-27 23:01 ` Dave Chinner
2010-05-27 23:01 ` Dave Chinner
2010-05-27 23:01 ` Dave Chinner
2010-05-25 8:53 ` [PATCH 4/5] superblock: add filesystem shrinker operations Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-27 20:32 ` Andrew Morton
2010-05-27 20:32 ` Andrew Morton
2010-05-27 20:32 ` Andrew Morton
2010-05-25 8:53 ` [PATCH 5/5] xfs: make use of new shrinker callout Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-25 8:53 ` Dave Chinner
2010-05-26 16:44 ` [PATCH 0/5] Per superblock shrinkers V2 Nick Piggin
2010-05-26 16:44 ` Nick Piggin
2010-05-26 16:44 ` Nick Piggin
2010-05-27 20:32 ` Andrew Morton
2010-05-27 20:32 ` Andrew Morton
2010-05-27 20:32 ` Andrew Morton
2010-05-28 0:30 ` Dave Chinner
2010-05-28 0:30 ` Dave Chinner
2010-05-28 0:30 ` Dave Chinner
2010-05-28 7:42 ` Artem Bityutskiy
2010-05-28 7:42 ` Artem Bityutskiy
2010-05-28 7:42 ` Artem Bityutskiy
2010-05-28 7:42 ` Artem Bityutskiy
2010-07-02 12:13 ` Christoph Hellwig
2010-07-02 12:13 ` Christoph Hellwig
2010-07-02 12:13 ` Christoph Hellwig
2010-07-12 2:41 ` Dave Chinner
2010-07-12 2:41 ` Dave Chinner
2010-07-12 2:41 ` Dave Chinner
2010-07-12 2:52 ` Christoph Hellwig
2010-07-12 2:52 ` Christoph Hellwig
2010-07-12 2:52 ` Christoph Hellwig
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=20100527064631.GK22536@laptop \
--to=npiggin@suse.de \
--cc=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.