On Mon, Nov 15, 2010 at 10:16:08PM +0100, Christoph Hellwig wrote: > On Mon, Nov 15, 2010 at 04:32:30PM +1100, Nick Piggin wrote: > > I mean, your dentry lru modification patch really didn't need to be > > pulled ahead of my other patches and and subtly changed. That just > > scatters wreckage throughout my patchset, which goes beyond just > > merging things up but also all the stress testing and verification I've > > done goes out the window too. > > There's a lot more dcache cleanups that need to go in before we can > do the lock splitting in a sensible way. I have started doing that a > couple of weeks ago while you were away. I've been keeping this back > in the hope that we could the mud fight and get back to the table > working together. My tree is obviously there, I've been wanting reviews and suggestions for months. > Any good way to encourage you to stick to the techical feedback instead > of two or three flames in reply to any disagreement by others? Also Yes, I'll stick to the actual technical feedback because I've decided to ignore all the other crap. By now they seem immune to flames, so it's pointless. > I'd be very happy you could stop sending me personal accusations of > a troll. Like when I explained (for the Nth time) why SLAB_DESTROY_BY_RCU was difficult for rcu-walk, and not much point for inode hash lookup, which you then ignored and posted your usual wrong FUD? "Dave sent a patch for it, which looks much better to me. Nick thinks it doesn't work for his store free path walk, but I haven't seen an explanation why exactly." Any good way to encourage you to actually follow what's going on, and maybe *read* my emails and give me the benefit of the doubt instead of assuming I'm wrong? > > Yes, I may not have the thing structured *exactly* as you want it, but > > really, unless it is a real problem, just look at the big picture a bit > > more. > > In VFS land we've done pretty well with doing cleanups before locking > or algorithm changes to make them smaller and better to audit. It's not > just my opinion, ask Al for his even more fine grained split up request > for the inode_lock splitup. I think splitting things into these small > blocks and moving the cleanup bits to the beginning has helped that code > a lot. We found a couple of bugs, both in the initial patches and the > later version, and the final patches are very easy to understand and > verify. > > Yes, it is a lot more work, but the result does pay off. I know, I'm not saying they're always wrong. But there are always cleanups to do, and some cleanup patches which don't do much to help a bigger pending transformation can be just as easily put after such a work. -- 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
