Re: [PATCH] locking/rwlocks: do not starve writers

[Eric Dumazet]

On Fri, Jun 17, 2022 at 9:35 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Jun 17, 2022 at 2:25 PM Eric Dumazet <edumazet@xxxxxxxxxx> 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.
>

I am converting RAW sockets to RCU.

We will likely need to use RCU in place of rwlock in most networking code.