linux-kernel - [announce] vfs-scale git tree update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 Jan 2011 21:25:34 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [announce] vfs-scale git tree update

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/