All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [announce] vfs-scale git tree update
Date: Wed, 5 Jan 2011 21:25:34 +1100	[thread overview]
Message-ID: <20110105102534.GA6679@amd> (raw)

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:
* Updated to 2.6.37 (Documentation/filesystems/Locking clash)
* Switch names of vfsmount scalable counter helpers suggested by Andreas
* Most significant are changes in Documentation/filesystems/path-lookup.txt
  attempt to make it more readable, consistent and informative. Add some
  interesting rcu-walk path lookup success and behaviour statistics.

Status:
* Linus is planning to merge. It's never too late for review, though.
* linux-next has been uneventful, but I don't think it nearly covers all
  interesting and fiddly use cases.
* Still has the barrier-less __seqcount optimisation that Linus didn't
  like; I like the idea of a seqcount-switch API, but it just didn't
  seem to fit well here. Let's leave that on the todo list?

Future dcache / name lookup work:
* Per-zone LRUs. Patch is simple and ready, but performance bisecting
  might be a bit easier if we hold off. Also inode LRUs should be done at
  the same time.
* Filesystems will need to start implementing rcu-walk aware dentry
  and permission ops. They've got simple examples to follow.
* Rename scaling. The rename seqlock can explode on large systems,
  getting into strange conditions where lookup performance crashes.
  It is also a global lock for renames. Quite simple to break it up and
  fix lookup performance and provide linear vfs scalability for parallel
  same-directory renames (if they are in different directories). Doesn't
  need to be merged yet, though.
* Further optimise name string copying and comparison (may be as much as
  10-20% in that).
* rcu-walk for symlinks. A bit tricky, not impossible.


             reply	other threads:[~2011-01-05 10:25 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 10:25 Nick Piggin [this message]
2011-01-05 21:00 ` [announce] vfs-scale git tree update Anca Emanuel
2011-01-06  2:12 ` Jongman Heo
2011-01-07  0:09   ` Nick Piggin
2011-01-07  0:59     ` Chris Ball
2011-01-07  1:41       ` Linus Torvalds
2011-01-07  2:03         ` Chris Ball
  -- strict thread matches above, loose matches on Subject: below --
2011-01-07  7:58 Nick Piggin
2011-01-11 16:34 ` Alex Elder
2011-01-11 16:51   ` Linus Torvalds
2011-01-11 17:57     ` Alex Elder
2011-01-11 18:13       ` Linus Torvalds
2011-01-11 18:13         ` Linus Torvalds
2011-01-12  3:55         ` Nick Piggin
2011-01-12  3:55           ` Nick Piggin
2011-01-12  3:59       ` Ian Kent
2011-01-12  4:06         ` Nick Piggin
2011-01-12  4:06         ` Linus Torvalds
2011-01-12  4:06           ` Linus Torvalds
2011-01-12  4:41           ` Ian Kent
2011-01-12  5:17             ` Ian Kent
2011-01-13  1:01               ` Nick Piggin
2011-01-13  1:48                 ` Ian Kent
2011-01-13  2:14                   ` Nick Piggin
2011-01-13  3:20                     ` Ian Kent
2011-01-13  3:22                       ` Nick Piggin
2011-01-12  4:15         ` Ian Kent
2011-01-12 20:11           ` Alex Elder
2011-01-13  2:23             ` Ian Kent
2011-01-13  3:03               ` Ian Kent
2011-01-13 17:09                 ` Alex Elder
2011-01-12  4:49         ` Aneesh Kumar K. V
2011-01-12  5:01           ` Ian Kent
2011-01-13  0:58             ` Nick Piggin
2011-01-13  1:46               ` Ian Kent
2010-12-22  9:53 Nick Piggin
2010-12-22 10:22 ` Sedat Dilek
2010-12-22 10:38 ` Sedat Dilek
2010-12-22 10:38   ` Sedat Dilek

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=20110105102534.GA6679@amd \
    --to=npiggin@kernel.dk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.