From: Al Viro <viro@ZenIV.linux.org.uk>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCHSET][RFC][CFT] parallel lookups
Date: Sat, 16 Apr 2016 04:27:51 +0100 [thread overview]
Message-ID: <20160416032750.GW25498@ZenIV.linux.org.uk> (raw)
In-Reply-To: <958A657E-1983-4695-8869-4E03FEBA2F90@dilger.ca>
On Fri, Apr 15, 2016 at 09:02:02PM -0600, Andreas Dilger wrote:
> Looks very interesting, and long awaited. How do you see the parallel
> operations moving forward? Staying as lookup only, or moving on to parallel
> modifications as well?
lookup + readdir. Not even atomic_open at this point, and that's the
route I'd suggest for modifiers - i.e. a combined lookup + mkdir, etc.
operations. But we'd really need to sort atomic_open pathway out first...
Let's discuss that at LSFMM, corridor track if needed. With lookups I'd been
able to keep the surgery site pretty much entirely in VFS proper - fs/dcache.c
and (after earlier massage) a single function in fs/namei.c. With readdir
it'll be somewhat more invasive - pre-seeding dcache is done in a bunch of
filesystems right now (mostly the network ones, where readdir request is
equivalent to bulk lookup, as well as synthetic-inodes ones a-la procfs)
and it'll need to be regularized; ncpfs is particularly nasty, what with its
case-changing crap), but at least it will be reasonably compact. For
atomic_open, and worse yet - mkdir/mknod/symlink/link/unlink/rmdir/rename
it will really dip into filesystem code. A lot.
FWIW, I agree that relying on i_mutex^Wi_rwsem for dcache protection is
something worth getting rid of in the longer term. But that protection is
there right now, and getting rid of that will take quite a bit of careful
massage. I don't have such a transition plotted yet; not enough information
at the moment, and I seriously suspect that atomic_open would be the best
place to start. If nothing else, there are reasonably few instances of that
puppy. Moreover, we badly need to regularize the paths around do_last() -
right now they are messy as hell. Once that is sorted out, we'll be in better
position to deal with the rest of directory-modifying operations.
prev parent reply other threads:[~2016-04-16 3:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-16 0:52 [PATCHSET][RFC][CFT] parallel lookups Al Viro
2016-04-16 0:55 ` [PATCH 01/15] security_d_instantiate(): move to the point prior to attaching dentry to inode Al Viro
2016-04-16 0:55 ` [PATCH 02/15] kernfs: use lookup_one_len_unlocked() Al Viro
2016-04-16 0:55 ` [PATCH 03/15] configfs_detach_prep(): make sure that wait_mutex won't go away Al Viro
2016-04-16 0:55 ` [PATCH 04/15] ocfs2: don't open-code inode_lock/inode_unlock Al Viro
2016-04-16 0:55 ` [PATCH 05/15] orangefs: " Al Viro
2016-04-16 0:55 ` [PATCH 06/15] reiserfs: open-code reiserfs_mutex_lock_safe() in reiserfs_unpack() Al Viro
2016-04-16 0:55 ` [PATCH 07/15] reconnect_one(): use lookup_one_len_unlocked() Al Viro
2016-04-18 19:23 ` J. Bruce Fields
2016-04-16 0:55 ` [PATCH 08/15] ovl_lookup_real(): " Al Viro
2016-04-16 0:55 ` [PATCH 09/15] lookup_slow(): bugger off on IS_DEADDIR() from the very beginning Al Viro
2016-04-16 0:55 ` [PATCH 10/15] __d_add(): don't drop/regain ->d_lock Al Viro
2016-04-24 18:09 ` Jeff Layton
2016-04-24 19:21 ` Al Viro
2016-04-16 0:55 ` [PATCH 11/15] beginning of transition to parallel lookups - marking in-lookup dentries Al Viro
2016-04-16 0:55 ` [PATCH 12/15] parallel lookups machinery, part 2 Al Viro
2016-04-16 0:55 ` [PATCH 13/15] parallel lookups machinery, part 3 Al Viro
2016-04-18 20:45 ` J. Bruce Fields
2016-04-16 0:55 ` [PATCH 14/15] parallel lookups machinery, part 4 (and last) Al Viro
2016-04-16 0:55 ` [PATCH 15/15] parallel lookups: actual switch to rwsem Al Viro
2016-04-16 3:02 ` Andreas Dilger
2016-04-16 3:31 ` Al Viro
2016-04-16 3:02 ` [PATCHSET][RFC][CFT] parallel lookups Andreas Dilger
2016-04-16 3:27 ` Al Viro [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=20160416032750.GW25498@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adilger@dilger.ca \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 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.