From: Eric Dumazet <eric.dumazet@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nick Piggin <npiggin@kernel.dk>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [patch 1/6] fs: icache RCU free inodes
Date: Tue, 09 Nov 2010 17:21:38 +0100 [thread overview]
Message-ID: <1289319698.2774.16.camel@edumazet-laptop> (raw)
In-Reply-To: <AANLkTi=b3dEmoTgrJ2xMTUzgM-mUQNNx6J9jeLq2=mtf@mail.gmail.com>
Le mardi 09 novembre 2010 à 08:02 -0800, Linus Torvalds a écrit :
> On Tue, Nov 9, 2010 at 4:46 AM, Nick Piggin <npiggin@kernel.dk> wrote:
> > So here is the inode RCU code. It's obviously not worth doing until the
> > actual rcu-walk path walking is in, but I'd like to get opinions on it.
> > It would be nice to merge it in Al's tree at some point, though.
>
> Remind me why it wasn't sufficient to just use SLAB_DESTROY_BY_RCU?
>
> Especially if we still lock things for the actual (few) inode list
> operations, the added complexity of actually freeing _individual_
> inodes by RCU seems to be a bad thing.
>
> The only thing we care about is the pathname walk - there are no other
> inode operations that are common enough to worry about. And the only
> thing _that_ needs is the ability to look at the inode under RCU, and
> SLAB_DESTROY_BY_RCU should be entirely sufficient for that.
>
> But we had some discussion about this long ago, and I may have
> forgotten some of the context.
>
David Chinner sent a patch using SLAB_DESTROY_BY_RCU
You can see problems using this fancy thing :
- Need to use slab ctor() to not overwrite some sensitive fields of
reused inodes.
(spinlock, next pointer)
- Fancy algo to detect an inode moved from one chain to another. Lookups
should be able to detect and restart their loop.
- After a match, need to get a stable reference on inode (lock), then
recheck the keys to make sure the target inode is the right one.
http://www.gossamer-threads.com/lists/linux/kernel/1298710
A bit tricky, but doable IMHO, especially if covering only the main
lookup. The seldom used can still get a (spin)lock.
next prev parent reply other threads:[~2010-11-09 16:21 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 12:46 [patch 1/6] fs: icache RCU free inodes Nick Piggin
2010-11-09 12:47 ` [patch 2/6] fs: icache avoid RCU freeing for pseudo fs Nick Piggin
2010-11-09 12:58 ` [patch 3/6] fs: dcache documentation cleanup Nick Piggin
2010-11-09 16:24 ` Christoph Hellwig
2010-11-09 22:06 ` Nick Piggin
2010-11-10 16:27 ` Christoph Hellwig
2010-11-09 13:01 ` [patch 4/6] fs: d_delete change Nick Piggin
2010-11-09 16:25 ` Christoph Hellwig
2010-11-09 22:08 ` Nick Piggin
2010-11-10 16:32 ` Christoph Hellwig
2010-11-11 0:27 ` Nick Piggin
2010-11-11 22:07 ` Linus Torvalds
2010-11-09 13:02 ` [patch 5/6] fs: d_compare change for rcu-walk Nick Piggin
2010-11-09 16:25 ` Christoph Hellwig
2010-11-10 1:48 ` Nick Piggin
2010-11-09 13:03 ` [patch 6/6] fs: d_hash " Nick Piggin
2010-11-09 14:19 ` [patch 1/6] fs: icache RCU free inodes Andi Kleen
2010-11-09 21:36 ` Nick Piggin
2010-11-10 14:47 ` Andi Kleen
2010-11-11 4:27 ` Nick Piggin
2010-11-09 16:02 ` Linus Torvalds
2010-11-09 16:21 ` Christoph Hellwig
2010-11-09 21:48 ` Nick Piggin
2010-11-09 16:21 ` Eric Dumazet [this message]
2010-11-09 17:08 ` Linus Torvalds
2010-11-09 17:15 ` Christoph Hellwig
2010-11-09 21:55 ` Nick Piggin
2010-11-09 22:05 ` Nick Piggin
2010-11-12 1:24 ` Nick Piggin
2010-11-12 4:48 ` Linus Torvalds
2010-11-12 6:02 ` Nick Piggin
2010-11-12 6:49 ` Nick Piggin
2010-11-12 17:33 ` Linus Torvalds
2010-11-12 23:17 ` Nick Piggin
2010-11-15 1:00 ` Dave Chinner
2010-11-15 4:21 ` Nick Piggin
2010-11-16 3:02 ` Dave Chinner
2010-11-16 3:49 ` Nick Piggin
2010-11-17 1:12 ` Dave Chinner
2010-11-17 4:18 ` Nick Piggin
2010-11-17 5:56 ` Nick Piggin
2010-11-17 6:04 ` Nick Piggin
2010-11-09 21:44 ` Nick Piggin
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=1289319698.2774.16.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@kernel.dk \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).