This is my sketch for improving dcache locking scalability. So far I've only really been looking at core code to get an idea of how it might look, so most configurable functionality is broken (and unfortunately it might well be something in there which will cause a fundamental problem for me). But there is a *lot* of stuff to go through, so I like to just get some early opinions of this. I have tried to split it as nicely as possible. Patch splitting still needs a bit more work, but it is not too bad hopefully to review. It seems to break naturally into 3 phases: - First phase is to add new locks and rules to protect specific data structures and dentry fields. This attempts to be as simple and dumb replacement as possible, to make review easier. - Second phase is to remove dcache_lock after it is not protecting anything itself. - Last phase is to improve existing locking schemes, and improve the scalability of the newly added locks. It's nowhere near complete, but it is running and relatively stable on configs where it compiles. As far as core locking changes go for this project, I still need to make nr_dentry into a per-cpu counter, and break up the LRU lock (which is the last remaining global lock broken out of dcache_lock). LRU lock currently naturally splits into per-sb locking, but that's not satisfying because we also want really good scalability within a single sb. I think per-memory-zone LRU lists and locking might be a good idea because it scales with socket count and also makes better NUMA targetted dcache reclaim possible. Making LRU more lazy might also be a good idea to reduce locking. -- 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
