linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: rcu-walk and dcache scaling tree update and status
@ 2010-12-13 16:48 Sedat Dilek
  2010-12-13 23:21 ` Stephen Rothwell
  0 siblings, 1 reply; 19+ messages in thread
From: Sedat Dilek @ 2010-12-13 16:48 UTC (permalink / raw)
  To: Nick Piggin; +Cc: LKML, linux-fsdevel, Stephen Rothwell

Hi,

I will give this new refreshed patchset a try (testing against
systemd-v15, vfat problem I reported) with none-BKL-config of course.

If linux-next will be the new base, then please rebase on it (see below).
(Last time I solved the CONFLICTs manually).

Regards,
- Sedat -

P.S.:

$ cd /mnt/sdb5/linux-kernel/linux-next

$ git log -1 | cat
commit 455b71004aa0d5cb899dc4df34892265e7486b70
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Mon Dec 13 16:15:19 2010 +1100

    Add linux-next specific files for 20101213

    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
vfs-scale-working:vfs-scale-working
remote: Counting objects: 1196, done.
remote: Compressing objects: 100% (80/80), done.
remote: Total 931 (delta 866), reused 915 (delta 851)
Receiving objects: 100% (931/931), 207.90 KiB | 376 KiB/s, done.
Resolving deltas: 100% (866/866), completed with 258 local objects.
>From git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin
 * [new branch]      vfs-scale-working -> vfs-scale-working
Auto-merging Documentation/filesystems/Locking
Removing Documentation/filesystems/dentry-locking.txt
Auto-merging Documentation/filesystems/vfs.txt
Auto-merging fs/anon_inodes.c
Auto-merging fs/ceph/dir.c
Auto-merging fs/ceph/inode.c
Auto-merging fs/ceph/mds_client.c
Auto-merging fs/cifs/cifsfs.c
Auto-merging fs/cifs/inode.c
Auto-merging fs/cifs/readdir.c
Auto-merging fs/coda/inode.c
Auto-merging fs/ecryptfs/inode.c
Auto-merging fs/ecryptfs/main.c
Auto-merging fs/ext3/super.c
Auto-merging fs/ext4/super.c
Auto-merging fs/fuse/dir.c
Auto-merging fs/fuse/inode.c
CONFLICT (content): Merge conflict in fs/fuse/inode.c
Auto-merging fs/gfs2/ops_inode.c
Auto-merging fs/hfsplus/dir.c
Auto-merging fs/hfsplus/hfsplus_fs.h
Auto-merging fs/hfsplus/super.c
Auto-merging fs/namei.c
Auto-merging fs/nfs/dir.c
Auto-merging fs/nfs/inode.c
Auto-merging fs/nfsd/vfs.c
Auto-merging fs/nilfs2/super.c
Auto-merging fs/ocfs2/super.c
Auto-merging fs/proc/base.c
Auto-merging fs/super.c
CONFLICT (content): Merge conflict in fs/super.c
Auto-merging fs/udf/super.c
Auto-merging include/linux/fs.h
Auto-merging include/linux/fsnotify.h
Auto-merging include/linux/fsnotify_backend.h
Auto-merging include/linux/security.h
Auto-merging mm/filemap.c
Auto-merging mm/shmem.c
Auto-merging mm/slab.c
Auto-merging mm/slub.c
Auto-merging net/socket.c
Auto-merging security/selinux/selinuxfs.c
Automatic merge failed; fix conflicts and then commit the result.
- EOT-

^ permalink raw reply	[flat|nested] 19+ messages in thread
* rcu-walk and dcache scaling tree update and status
@ 2010-12-13  2:37 Nick Piggin
  0 siblings, 0 replies; 19+ messages in thread
From: Nick Piggin @ 2010-12-13  2:37 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton, Al Viro, Stephen Rothwell,
	linux-fsdevel

The vfs-scale branch has had some progress, but it is now requiring
wider testing and detailed review, particularly of the fine details of
dcache_lock lifting, and rcu-walk synchronisation details and
documentation.

Linus has suggested pretty strongly that he wants to pull this in the
next merge window (recently, that "inodes will be RCU freed in 2.6.38"
in an urelated discussion). As far as I know, that's what he's going to
do. I'd like to get this some time in linux-next to improve test
coverage (many filesystems I can't even test, so there are bound to be a
few silly crashes). Stephen, how do I arrange that?

>From my point of view, it has had nowhere near enough review,
particularly I want Al to be happy with it, filesystem changes looked at
and tested by respective fs maintainers, and anybody who is good at
concurrency. However, if Linus still wants to merge it to kick things
along, I am not going to stop him this time, because I have no known
bugs or pending changes required.

I, like everybody else, would prefer bugs or design flaws to be found
*before* it goes upstream, of course. I would be happy to spend time on
irc with reviewers (ask me offline). And if anybody has reasonable
concerns or suggestions, I will be happy to take that into account. I
will not flame anybody who reads my replies, even if it takes a while
for one or both of us to understand.

Documentation/filesystems/path-lookup.txt is a good place to start
reviewing the fun stuff. I would much appreciate review of documentation
and comments too, if anything is not clear, omitted, or not matching the
code.

Also, please keep an eye on the end result when reviewing patches.
Particularly the locking patches before dcache_lock is lifted, these are
supposed to provide a lock coverage to lift dcache_lock with minimal
complexity. They are not supposed to be nice looking code that you'd
want to run on your production box, they are supposed to be nice
changesets (from a review and verification point of view).

Git tree is here:

  git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git

Branch is:

    vfs-scale-working

Changes since last posting:
* Add a lot more comments for rcu-walk code and functions
* Fix reported d_compare vfat crash
* Incorporate review suggestions
* Make rcu-walk bail out if we have to call a security subsystem
* Fix for filesystems rewriting dentry name in-place
* Audit d_seq barrier write-side, add a few places where it was missing
* Optimised dentry memcmp

Testing:
Testing filesystems is difficult, particularly remote filesystems, and
ones without mkfs packaged in debian. I'm running ltp and xfstests among
others, but those cover a tiny portion of what you can do with the
dcache. The more testing the merrier.

I have been unable to break anything for a long time, but the race
windows can be tiny. I've been trying to insert random delays into
different parts of critical sections, and write tests specifically
targetting particular races, but that's slow going -- review of locking,
or testing on different configurations should be much more productive.

Final note:
You won't be able to reproduce the parallel path walk scalability
numbers that I've posted, because the vfsmount refcounting scalability
patch is not included. I have a new idea for that now, so I'll be asking
for comments with that soon.

Thanks,
Nick


^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2010-12-16  2:27 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20101213023733.GB6522@amd>
2010-12-13  2:42 ` [patch] fs: scale vfsmount refcount (was Re: rcu-walk and dcache scaling tree update and status) Nick Piggin
2010-12-13  3:31   ` Nick Piggin
2010-12-13  3:43     ` Nick Piggin
2010-12-13  7:25   ` Eric Dumazet
2010-12-13  8:33     ` Nick Piggin
2010-12-14 12:40     ` Nick Piggin
2010-12-15  8:16       ` Andreas Dilger
2010-12-15 10:24         ` Nick Piggin
2010-12-13  2:53 ` rcu-walk and dcache scaling tree update and status Ed Tomlinson
2010-12-13  2:59   ` Nick Piggin
2010-12-13  3:45     ` Stephen Rothwell
2010-12-13  3:50       ` Nick Piggin
2010-12-13  3:40 ` Stephen Rothwell
2010-12-13  3:48   ` Nick Piggin
2010-12-14  0:03     ` Stephen Rothwell
2010-12-14  0:16       ` Stephen Rothwell
2010-12-13 16:48 Sedat Dilek
2010-12-13 23:21 ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2010-12-13  2:37 Nick Piggin

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).