linux-kernel - Quick merge window note..

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]

Message-ID: <AANLkTi=eNucM5d=+zq5euz3dZirJEhPaH9f9ZXuHymEM@mail.gmail.com>
Date:	Fri, 7 Jan 2011 17:32:46 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:	Nick Piggin <npiggin@...nel.dk>, Al Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, David Miller <davem@...emloft.net>
Subject: Quick merge window note..

So I've obviously been merging eagerly the last couple of days, but
I'm taking most of the weekend off, and I thought I'd just point
people at the fact that I merged the somewhat scary (but very
impressive) lockless name lookup tree from Nick today.

It's scary because this is some very core code, and the new RCU lookup
model is way more clever and subtle than the old dentry_lock spinlock.

But it's rather impressive and I really wanted to merge it, because
some of the performance numbers are pretty stunning. For example, a
hot-cache "find . -size" on my home directory (which basically just
does name lookups to get the stat information for every file
recursively) became 35% faster. And that's the _unthreaded_ case. Not
some odd high-end scalability thing, and not some recompiled binary
taking advantage of new facilities. Pathname lookup is just simply
faster.

On the scary side, it's worth noticing that if you see any problems,
and you think it might be due to the new rcu lookup, rather than
bisect _everything_ (the merge window has already brought in 3700+
commits), it may be worth just checking the VFS scale tip itself.
That's fairly easy, because it's based on plain 2.6.37 (which if it
isn't stable for you, we have bigger problems than the RCU lookup),
and is just 57 commits up until commit b3e19d924b6e ("fs: scale
mntget/mntput").

So rather than bisect the 3700+ commits, start out by trying that one
commit first.

Of course, I've already bisected one problem (firmware loading
"feature"), and that wasn't in the RCU pathname lookup, so maybe I'm
pointing out the new name lookup for no good reason. Traditionally, I
think most of our regressions by far tend to be in drivers etc rather
than core code and me being worried about the core may be silly.

(And btw, I do have more pull requests pending, and no, I didn't miss
them just because I haven't pulled yours yet. But I'm going to give it
a short rest, and continue pulling on Sunday)

                                 Linus
--
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/