Messages in this thread | | | Date | Fri, 28 Jan 2005 03:56:40 -0800 | From | William Lee Irwin III <> | Subject | Re: Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15) |
| |
* Esben Nielsen <simlo@phys.au.dk> wrote: >> [...] I wanted to start looking at fixing that because it ought to >> hurt scalability quite a bit - and even on UP create a few unneeded >> task-switchs. [...]
On Fri, Jan 28, 2005 at 08:38:56AM +0100, Ingo Molnar wrote: > no, it's not a big scalability problem. rwlocks are really a mistake - > if you want scalability and spinlocks/semaphores are not enough then one > should either use per-CPU locks or lockless structures. rwlocks/rwsems > will very unlikely help much.
I wouldn't be so sure about that. SGI is already implicitly relying on the parallel holding of rwsems for the lockless pagefaulting, and Oracle has been pushing on mapping->tree_lock becoming an rwlock for a while, both for large performance gains.
* Esben Nielsen <simlo@phys.au.dk> wrote: >> However, the more I think about it the bigger the problem:
On Fri, Jan 28, 2005 at 08:38:56AM +0100, Ingo Molnar wrote: > yes, that complexity to get it perform in a deterministic manner is why > i introduced this (major!) simplification of locking. It turns out that > most of the time the actual use of rwlocks matches this simplified > 'owner-recursive exclusive lock' semantics, so we are lucky. > look at what kind of worst-case scenarios there may already be with > multiple spinlocks (blocker.c). With rwlocks that just gets insane.
tasklist_lock is one large exception; it's meant for concurrency there, and it even gets sufficient concurrency to starve the write side.
Try test_remap.c on mainline vs. -mm to get a microbenchmark-level notion of the importance of mapping->tree_lock being an rwlock (IIRC you were cc:'d in at least some of those threads).
net/ has numerous rwlocks, which appear to frequently be associated with hashtables, and at least some have some relevance to performance.
Are you suggesting that lockless alternatives to mapping->tree_lock, mm->mmap_sem, and tasklist_lock should be pursued now?
-- wli - 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/
| |