Re: [GIT PULL] adaptive spinning mutexes

[Linus Torvalds <torvalds@linux-foundation.org>]

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