On Tue, Nov 16, 2010 at 02:02:43PM +1100, Dave Chinner wrote: > On Mon, Nov 15, 2010 at 03:21:00PM +1100, Nick Piggin wrote: > > This is 30K inodes per second per CPU, versus nearly 800K per second > > number that I measured the 12% slowdown with. About 25x slower. > > Hi Nick, the ramfs (800k/12%) numbers are not the context I was > responding to - you're comparing apples to oranges. I was responding to > the "XFS [on a ramdisk] is about 4.9% slower" result. Well xfs on ramdisk was (85k/4.9%). A a lower number, like 30k, I would expect that should be around 1-2% perhaps. And when in the context of a real workload that is not 100% CPU bound on creating and destroying a single inode, I expect that to be well under 1%. Like I said, I never disputed a potential regression, but I have looked for workloads that have a detectable regression and have not found any. And I have extrapolated microbenchmark numbers to show that it's not going to be a _big_ problem even in a worst case scenario. Based on that, and the fact that complexity of rcu-walk goes up quite a bit with SLAB_DESTROY_BY_RCU, I explained why I want to go with RCU first. I am much more worried about complexity and review coverage and maintainability than a small worst case regression in some rare (non-existant) workloads. I say non existant because if anybody actaully has a workload that tries to create and destroy inodes fast, they would have been yelling at the top of their lungs already because the vfs was totally unscalable for them, let alone most filesystems. Ie. we have quite strong empirical evidence that people are _not_ hitting this terribly hard. The first real complaint was really not long ago by google, and that was due to sockets workload, not files. I think that is quite a reasonable position. I would definitely like to see and hear of any numbers or workloads that you can suggest I try, but really I still want to merge rcu-walk first and then do an incremental SLAB RCU patch on top of that as my preferred approach to merging it. Thanks, Nick -- 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
