On Thu, 15 Jan 2009, Chris Mason wrote: > On Thu, 2009-01-15 at 10:16 -0800, Linus Torvalds wrote: > > > > Umm. Except if you wrote the code nicely and used spinlocks, you wouldn't > > hold the lock over all those unnecessary and complex operations. > > While this is true, there are examples of places we should expect > speedups for this today. Sure. There are cases where we do have to use sleeping things, because the code is generic and really can't control what lower levels do, and those lower levels have to be able to sleep. So: > Concurrent file creation/deletion in a single dir will often find things > hot in cache and not have to block anywhere (mail spools). The inode->i_mutex thing really does need to use a mutex, and spinning will help. Of course, it should only help when you really have lots of concurrent create/delete/readdir in the same directory, and that hopefully is a very rare load in real life, but hey, it's a valid one. > Concurrent O_DIRECT aio writes to the same file, where i_mutex is > dropped early on. Won't the actual IO costs generally dominate in everything but trivial benchmarks? > pipes should see a huge improvement. Hmm. Pipes may be interesting, but on the other hand, the cases that would see huge improvements would tend to be the cases where the biggest performance gain is from running both sides on the same CPU. The only case where a pipe gets really contended is when both producer and consumer basically do nothing with the data, so the biggest costs is the copy in kernel space (read: pure benchmarking, no real load), and then you often get better performance by scheduling on a single CPU due to cache effects and no lock bouncing. Linus -- 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
