On Wed, Sep 03, 2025 at 10:40:12AM +0200, Sebastian Andrzej Siewior wrote: > On 2025-08-26 10:43:20 [+0200], Nam Cao wrote: > > On Tue, Jul 15, 2025 at 02:46:34PM +0200, Nam Cao wrote: > > > The ready event list of an epoll object is protected by read-write > > > semaphore: > > > > > > - The consumer (waiter) acquires the write lock and takes items. > > > - the producer (waker) takes the read lock and adds items. > > > > > > The point of this design is enabling epoll to scale well with large number > > > of producers, as multiple producers can hold the read lock at the same > > > time. > > > > > > Unfortunately, this implementation may cause scheduling priority inversion > > > problem. Suppose the consumer has higher scheduling priority than the > > > producer. The consumer needs to acquire the write lock, but may be blocked > > > by the producer holding the read lock. Since read-write semaphore does not > > > support priority-boosting for the readers (even with CONFIG_PREEMPT_RT=y), > > > we have a case of priority inversion: a higher priority consumer is blocked > > > by a lower priority producer. This problem was reported in [1]. > > > > > > Furthermore, this could also cause stall problem, as described in [2]. > > > > > > Fix this problem by replacing rwlock with spinlock. > > > > Hi Christian, > > > > May I know your plan with this patch? Are you still waiting for something? > > > > You may still understandably be paranoid about epoll due to the last > > regression. But it's been weeks, and this patch is quite simple, so I start > > to wonder if it is forgotten. > > A friendly reminder. Sorry, this apparently fell through the cracks. Taken care of now!
