Messages in this thread | | | Date | Wed, 24 Jul 2002 19:25:38 -0700 | From | Andrew Morton <> | Subject | Re: [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/
| |