[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210827100742.naifk7js3ukpp3f2@linutronix.de>
Date: Fri, 27 Aug 2021 12:07:42 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: John Ogness <john.ogness@...utronix.de>
Cc: Frederic Weisbecker <frederic@...nel.org>,
linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Mike Galbraith <efault@....de>
Subject: Re: [RFC PATCH -RT] epoll: Fix eventpoll read-lock not writer-fair
in PREEMPT_RT
On 2021-08-26 22:36:04 [+0206], John Ogness wrote:
> On 2021-08-26, Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> > On 2021-08-25 15:27:54 [+0200], Frederic Weisbecker wrote:
…
> >> I guess making readlock writer fair is still not the plan so all I can
> >> propose is to make that rwlock build-conditional.
…
> > It is writer fair in a sense that once a writer attempts to acquire
> > the lock no new reader are allowed in.
> >
> > What you want is that the writer pi-boosts each reader which is what
> > is not done (multi reader boost). Long ago there was an attempt to
> > make this happen (I think with rwsem) but it turned out to be
> > problematic. There was a workaround by only allowing one reader and
> > doing PI as usual.
>
> This patch is essentially forcing that exact workaround for eventpoll.
Frederic ended the mail with "readlock is not writer fair" so I
explained that it is and he means something else and this is not not
coming. I also suggested between the lines that he might try to move
the reader side to RCU.
> John Ogness
Sebastian
Powered by blists - more mailing lists