Re: Success with new futex code from 2.6.0-test5

Ingo Molnar wrote:
> no need - i only wanted to know for sure that the 'freeze' things was
> indeed caused by suboptimal locking in the futex code. It was then
> probably just some 4-CPU race for the same lock, causing some real bad
> cacheline movements between CPUs.

Unfortunately there is one lock that is always taken and can't be
hashed: mmap_sem.  You won't see contention, but plenty of cacheline
movement.

Can you think of a good way to break up mmap_sem into something with
less cacheline movement in the read case?

Here's an example: split mmap_sem into an array of semaphores using
current CPU as hash key (it's ok if the value changes due to
scheduling), or anything else as hash key.  Reader just has to lock
one of them (any one), writer has to lock them all in order.

-- Jamie