lkml.org 
[lkml]   [2005]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

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