Re: Success with new futex code from 2.6.0-test5

On Wed, 10 Sep 2003, Jamie Lokier wrote:

> 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.

like brlocks.

well, if we make the read path completely per-CPU that will always
introduce some sort of cost on the write path. It could be made
statistical perhaps: there would be a 'readers faster' and a 'writers same
speed' mode - and if there had been like 5 reads in a row then the lock
switches over into the 'readers faster mode' - if 5 writes then the other
mode.

'readers faster' would be the brlock-alike array structure. 'writers same
speed' would be a central lock. Switchover between modes happens by
modifying a flag - this flag would not bounce if the access is either
typically read or typically write.

although a 128-entry lock table on a 128 CPU system certainly sounds like
overkill - but there's no other way to reduce bouncing but to make (some
of) the reference counters per-CPU.

	Ingo