On Sun, Oct 10, 2010 at 10:20:39AM +0200, Andi Kleen wrote: > > Certainly not for .37, where even the inode_lock splitup is pretty damn > > later. Nick disappearing for a few weeks and others having to pick up > > the work to sort it out certainly doesn't help. And the dcache_lock > > splitup is a much larget task than that anyway. Getting that into .38 > > is the enabler for doing more fancy things. And as Dave mentioned at > > least in the writeback area it's much better to sort out the algorithmic > > problems now than to blindly split some locks up more. > > I don't see why the algorithmic work can't be done in parallel > to the lock split up? > > Just the lock split up on its own gives us large gains here. What about actually starting to test the stuff headed towards Al's tree to verify your assumptions? It's nice to have a lot of people talking, but actually helping with review and testing would be more useful. Yes, lots of things could be done in parallel, but it needs people to actually work on it. And right now that's mostly Dave for the real work, with me trying to prepare a proper dcache series for .38, and Al doing some review. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
