On Fri, Jul 23, 2010 at 07:17:46AM -0400, Christoph Hellwig wrote: > I might sound like a broken record, but if you want to make forward > progress with this split it into smaller series. No I appreciate the advice. I put this tree up for people to fetch without posting patches all the time. I think it is important to test and to see the big picture when reviewing the patches, but you are right about how to actually submit patches on the ML. > What would be useful for example would be one series each to split > the global inode_lock and dcache_lock, without introducing all the > fancy new locking primitives, per-bucket locks and lru schemes for > a start. I've kept the series fairly well structured like that. Basically it is in these parts: 1. files lock 2. vfsmount lock 3. mnt refcount 4a. put several new global spinlocks around different parts of dcache 4b. remove dcache_lock after the above protect everything 4c. start doing fine grained locking of hash, inode alias, lru, etc etc 5a, 5b, 5c. same for inodes 6. some further optimisations and cleanups 7. store-free path walking This kind of sequence. I will again try to submit a first couple of things to Al soon. -- 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
