On Tue, 2010-09-14 at 18:26 -0400, Christoph Hellwig wrote: > Nick, > > what's the plan for going ahead with the VFS scalability work? We're > pretty late in the 2.6.36 cycle now and it would be good to get the next > batch prepared and reivew so that it can get some testing in -next. > > As mentioned before my preference would be the inode lock splitup and > related patches - they are relatively simple and we're already seeing > workloads where inode_lock really hurts in the writeback code. For the record, while I've been quiet here (really busy) I have run a bunch of pretty serious tests against the original set of patches (note: _not_ the latest bits in Nick's tree, I have those queued up but haven't gotten to them yet). So far I haven't seen any instability at all. (I did see one case in which a test that does a _lot_ of network traffic with tons of sockets saw a 20+% performance hit on a system with a relatively moderate number of cores but I haven't had the time to characterize it better and want to test against the newer bits in any event. Sorry to be so vague, I can't really be more specific at this point. Nailing this down is _also_ on my list.) Performance notwithstanding, I'm impressed with the stability of those original patches. I've run VM stress tests against it, FS stress tests, lots of benchmarks and a bunch of other stuff and it's solid, no crashes nor any anomalous behavior. That being the case, I would vote enthusiastically for bringing in the inode_lock splitup as soon as is feasible. -- Frank Mayhar <fmayhar@xxxxxxxxxx> Google, Inc. -- 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
