Nick Piggin <npiggin@xxxxxxxxx> writes: > There are 3 main parts to dcache scaling. This one primarily adds new locks > to take over dcache_lock, and some pre/post prep and streamlining patches. > > The second implements fine grained locking, and is rather trivial after > part 1. > > The third implements rcu-walk. rcu-walk depends on the first part, because it > relies on using d_lock to protect the state of the dentry (when converting from > rcu-walk to refcounted walk). Without the fine grained locing, we'd need to use > dcache_lock for that, which would be a step backwards to put into path walking > again. > > Comments? I read 15, 10, 8, 5, 4, 3, 1 so far (weird order, it showed that way in my reader :-) There was nothing surprising in any of those and they all seem to do what the description advertises. I was scared a bit by the upto 4 level dcache lock nestings, but I assume those will get better again when everything is done. At least from a quick look they seem to be all in the right order (I assume you attempted some runtime coverage with lockdep too, right?) For some of the hash lists it may become attractive to consider the newly posted lockless list, but it wasn't fully clear if that was easy to do (the lock protected a bit more than just the list node) For the level file system tree sweep changes it would be nice if there were semantic patches available. That would make it easier to verify the changes have been consistently done, by rerunning the patcher. You can add a Reviewed-by: Andi Kleen <ak@xxxxxxxxxxxxxxx> to the patches listed above. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- 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
