Re: [PATCH] generalized spin_lock_bit, take two

[Andrew Morton <akpm@zip.com.au>]

Robert Love wrote:
> 
> Andrew and Linus,
> 
> The attached patch implements bit-sized spinlocks via the following
> interfaces:
> 
>         spin_lock_bit(int nr, unsigned long * lock)
>         spin_unlock_bit(int nr, unsigned long * lock)
> 
> to abstract the current VM pte_chain locking and to fix the problem
> where the locks are not compiled away on UP.
> 

Do we really want to introduce another locking primitive?

pte_chain_lock is special, because we have so many struct page's,
and open-coding that locking is a good way to express that
specialness.  But if we go and formalise "spin_lock_bit" then
everyone will start using them, and that's not necessarily
a thing we want to happen?

I did some testing yesterday with fork/exec/exit-intensive
workloads and the contention rate on pte_chain_lock was 0.3%,
so the efficiency problems which Linus described are unlikely
to bite us in this particular application.  But if the usage
of spin_lock_bit() were to widen, some platforms may be impacted.

-