* Quick merge window note..
@ 2011-01-08 1:32 Linus Torvalds
2011-01-08 23:56 ` Greg KH
0 siblings, 1 reply; 2+ messages in thread
From: Linus Torvalds @ 2011-01-08 1:32 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Nick Piggin, Al Viro, Andrew Morton, Greg KH, David Miller
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Quick merge window note..
2011-01-08 1:32 Quick merge window note Linus Torvalds
@ 2011-01-08 23:56 ` Greg KH
0 siblings, 0 replies; 2+ messages in thread
From: Greg KH @ 2011-01-08 23:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Nick Piggin, Al Viro, Andrew Morton,
David Miller
On Fri, Jan 07, 2011 at 05:32:46PM -0800, Linus Torvalds wrote:
> 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").
Thanks for the heads up. In some initial testing here, it all looks
good to me.
greg k-h
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-01-09 0:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-08 1:32 Quick merge window note Linus Torvalds
2011-01-08 23:56 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox