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.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:18 EST