* Esben Nielsen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
