On Sun, Oct 10, 2010 at 02:03:09PM +0200, Andi Kleen wrote: > On Sun, Oct 10, 2010 at 04:37:49AM -0400, Christoph Hellwig wrote: > > but actually helping with review and testing would be more useful. > > Well the constant refactoring is certainly not helping with testing. That is the way of review cycles. The need for significant refactoring and reworking shows how much work the VFS maintainers consider still needs to be done on the patch set. > Also what typically happens is that if we don't fix all the serious > VFS locking issues (like Nick's patch kit) we just move from one bottle > neck to another. Sure, but at least there is a plan for dealing with them all and, most importantly, people committed to pushing it forward. Fundamentally, we need to understand the source of the lock contention problems before trying to fix them. Nick just hit them repeatedly with a big hammer until they went away.... > > 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. > > It was not clear to me what was so horrible with Nick's original > patchkit? Sure there were a few rough edges, but does it really > need to be fully redone? I think the trylock mess is pretty much universally disliked by anyone who looks at the VFS and writeback code on a daily basis. And IMO the level of nested trylock looping is generally indicative of getting the lock ordering strategy wrong in the first place. Not to mention that as soon as I tried to re-order cleanups to the front of the queue, it was pretty clear that it was going to be unmaintainable, too. > It certainly held up great to lots of testing, both at our side > and apparently Google's too. Not the least bit relevant, IMO, when the code ends up unmaintanable in the long term. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
