Messages in this thread | | | From | Eric Dumazet <> | Date | Fri, 17 Jun 2022 21:39:03 +0200 | Subject | Re: [PATCH] locking/rwlocks: do not starve writers |
| |
On Fri, Jun 17, 2022 at 9:35 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > 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. >
I am converting RAW sockets to RCU.
We will likely need to use RCU in place of rwlock in most networking code.
| |