Re: [PATCH] generalized spin_lock_bit, take two

Andrew Morton (akpm@zip.com.au)
Wed, 24 Jul 2002 19:25:38 -0700


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/