Messages in this thread | | | From | Eric Dumazet <> | Date | Fri, 17 Jun 2022 21:25:15 +0200 | Subject | Re: [PATCH] locking/rwlocks: do not starve writers |
| |
On Fri, Jun 17, 2022 at 9:19 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Fri, Jun 17, 2022 at 2:10 PM Eric Dumazet <edumazet@google.com> wrote: > > > > So I wonder why we replaced eventpoll spinlock with an rwlock. > > Yeah, usually we've actually gone the other way. > > Spinning rwlocks are seldom a big win, unless you can get some > secondary indirect win out of them. > > That secondary win is often: > > (a) unfairness is usually very good for throughput (iow, the very > unfairness that you hit may *be* the reason why it looked good in some > benchmark, and people decided "ok, let's do this"). > > (b) the special case of "interrupts take the lock for reading only" > thing that allows other readers to not disable interrupts > > IOW, the win of a spinning rwlock is not necessarily the "we allow > multiple concurrent readers" that you'd expect, because if you have > small sections of code you protect, that just isn't a big deal, and > the costs are in the lock bouncing etc. > > It's also worth pointing out that rwlocks are only unfair *if* they > hit that "reader from (soft)interrupt" case. Which means that such > cases *really* had better either have very very short locked regions > (with interrupts disabled), or they really need that (b) part above. > > And yes, the tasklist lock really needs the (b) part above. Disabling > interrupts for task traversal would be completely and entirely > unacceptable, because the traversal can actually be fairly expensive > (lots and lots of threads).
Interesting...
I think getrusage(RUSAGE_SELF) is blocking interrupts in the possible long loop:
do { accumulate_thread_rusage(t, r); } while_each_thread(p, t);
> > I suspect eventpoll just did the wrong thing. > > Linus
| |