Linux 2.6.35
in [Kernel]
|
Prev: Fix /proc/softirqs file formatting
Next: [ANNOUNCE] mtdev v1.0.8 -- Multitouch Protocol Translation Library
From: Nick Piggin on 2 Aug 2010 04:20 On Mon, Aug 02, 2010 at 10:32:04AM +1000, Stephen Rothwell wrote: > Hi all, > > On Sun, 1 Aug 2010 16:52:42 -0700 Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > > On a slightly happier note: one thing I do hope we can merge in the > > upcoming merge window is Nick Piggin's cool VFS scalability series. > > I've been using it on my own machine, and gone through all the commits > > (not that I shouldn't go through some of them some more), and am > > personally really excited about it. It's seldom we see major > > performance improvements in core code that are quite that noticeable, > > and Nick's whole RCU pathname lookup in particular just tickles me > > pink. > > To that end, Nick, can you please submit that tree for inclusion in > linux-next in case there are some interactions with some of the other > stuff there? (or send it all to Al, instead (or both), I guess.) Hi Stephen, I will work something out with Al and try to have something in linux-next ASAP. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 2 Aug 2010 04:30 On Mon, Aug 02, 2010 at 05:55:37PM +1000, Nick Piggin wrote: > I hate to say but I would like to see it mature for another release. It > should also clash a bit with Al's recent inode work that he'll want to > push. > > What I can do is send some of the ground work patches this time around, > put the tree into linux-next, and put reviewers on notice. > > I think it is all conceptually sound, but it will inevitably have some > bugs left to shake out, and things to be fixed on the review side. I > don't anticipate a problem that could not be fixed in the release cycle, > but I think aiming for post 2.6.36 is a bit fairer for vfs guys, > honestly. LSF is next week too, so most of them will be busy with travel > and such. But I do hope to discuss the vfs-scale patches there. What I'm most concerned bit merging everything in one go. It's a huge series and I'd rather see it start going in in batches over multiple kernel releases. Things like the fs_struct spinlock and some other preparatory patches should be ver easily to do for 2.6.36. Scaling the files and vfsmount locks should also be easily doable, but we need to sort out the struct file growth in the later. We really can't grow struct file by two pointers as that would have devasting effects on various workloads. What follows after that is the dcache_lock scaling which to seems the most immature bit of the series, and the one that showed by far the most problems in -RT. I'm very much dead set against merging that in ..36. I'd much rather see the inode_lock scaling or the lockless path walk going in before, but I haven't checked how complicated the reordering would be. The lockless path walk also is only rather theoretically useful until we do ACL checks lockless as we're having ACLs enabled pretty much everywhere at least in the distros. The per-zone shrinkers are another thing that's not directly related, I think they need a lot more discussion with the VM folks, and integrating with Dave's work in that area. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 2 Aug 2010 04:50 > The per-zone shrinkers are another thing that's not directly related, > I think they need a lot more discussion with the VM folks, and > integrating with Dave's work in that area. per-zone shrinkers don't cause so much impact to VM design except zone reclaim feature. So, if FS folks think it's ok, I'm not against this at all. btw, however, I haven't review such patch series in the detail yet. so perhaps I might post some bug fix later. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Rothwell on 2 Aug 2010 05:00 Hi Nick, On Mon, 2 Aug 2010 18:14:22 +1000 Nick Piggin <npiggin(a)suse.de> wrote: > > I will work something out with Al and try to have something in > linux-next ASAP. OK, great. -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au http://www.canb.auug.org.au/~sfr/
From: Christoph Hellwig on 2 Aug 2010 05:10
On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote: > .36. I'd much rather see the inode_lock scaling or the lockless path > walk going in before, but I haven't checked how complicated the > reordering would be. The lockless path walk also is only rather > theoretically useful until we do ACL checks lockless as we're having > ACLs enabled pretty much everywhere at least in the distros. From a quick look it seems like the inode_lock splitup can easily be moved forward, and it would help us with doing some work on the writeback side. The problem is that it would need rebasing ontop of both the vfs and writeback (aka block) trees. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |