lkml.org 
[lkml]   [2002]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] generalized spin_lock_bit, take two
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/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.182 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site