lkml.org 
[lkml]   [2022]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] locking/rwlocks: do not starve writers
    On Fri, Jun 17, 2022 at 2:25 PM Eric Dumazet <edumazet@google.com> wrote:
    >
    > Interesting...
    >
    > I think getrusage(RUSAGE_SELF) is blocking interrupts in the
    > possible long loop:

    Yeah, that looks bad.

    It needs that interrupt disable due to sighand->siglock, but normally
    we would expect to *not* have a big loop inside the siglock.

    Nasty.

    I wonder if this is possibly a situation where we should actually make
    siglock be a rwlock.

    But considering that this RUSAGE_SELF is hopefully a special case,
    maybe we could write it differently.

    Instead of taking the sighand lock, we might be able to iterate just
    over the regular thread list (using the tasklist lock), and then do
    the "does sighand match" as a one-off check in
    accumulate_thread_rusage().

    It's not like we even really need that strict locking there, I suspect.

    Anyway, I should have noted in my previous email that my "rwlock is
    often not the win you'd think it is" that that is only true for this
    *spinning* rwlock.

    For the actual sleeping reader-writer lock (down_read/down_write and
    friends), the whole "you can have multiple readers" is often a *huge*
    deal and very central to using a rwlock. It's literally just the
    spinning one that is often better as a spinlock unless you have those
    magical reasons to use it.

    Linus

    \
     
     \ /
      Last update: 2022-06-17 21:36    [W:4.095 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site