Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1380474
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCHSET][RFC][CFT] parallel lookups |
| Date | 2016-04-16 05:30 +0200 |
| Message-ID | <rop5M-5rX-5@gated-at.bofh.it> (permalink) |
| References | <romKB-3oC-3@gated-at.bofh.it> <rooMp-5jz-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCHSET][RFC][CFT] parallel lookups Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-16 03:00 +0200
[PATCH 01/15] security_d_instantiate(): move to the point prior to attaching dentry to inode Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-16 03:00 +0200
[PATCH 09/15] lookup_slow(): bugger off on IS_DEADDIR() from the very beginning Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-16 03:00 +0200
[PATCH 14/15] parallel lookups machinery, part 4 (and last) Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-16 03:00 +0200
[PATCH 15/15] parallel lookups: actual switch to rwsem Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-16 03:00 +0200
Re: [PATCH 15/15] parallel lookups: actual switch to rwsem Andreas Dilger <adilger@dilger.ca> - 2016-04-16 05:10 +0200
Re: [PATCH 15/15] parallel lookups: actual switch to rwsem Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-16 05:40 +0200
Re: [PATCHSET][RFC][CFT] parallel lookups Andreas Dilger <adilger@dilger.ca> - 2016-04-16 05:10 +0200
Re: [PATCHSET][RFC][CFT] parallel lookups Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-16 05:30 +0200
csiph-web