[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Zyb3yS6Whi5Na0lg@LQ3V64L9R2>
Date: Sat, 2 Nov 2024 21:10:49 -0700
From: Joe Damato <jdamato@...tly.com>
To: Hillf Danton <hdanton@...a.com>
Cc: netdev@...r.kernel.org, edumazet@...gle.com, willy@...radead.org,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-kernel@...r.kernel.org, mkarsten@...terloo.ca,
sridhar.samudrala@...el.com
Subject: Re: [PATCH net-next v4 5/7] eventpoll: Control irq suspension for
prefer_busy_poll
On Sun, Nov 03, 2024 at 07:39:25AM +0800, Hillf Danton wrote:
> On Sat, 2 Nov 2024 00:52:01 +0000 Martin Karsten <mkarsten@...terloo.ca>
> >
> > @@ -2005,8 +2032,10 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
> > * trying again in search of more luck.
> > */
> > res = ep_send_events(ep, events, maxevents);
> > - if (res)
> > + if (res) {
> > + ep_suspend_napi_irqs(ep);
>
> Leave napi irq intact in case of -EINTR.
(I've added Martin and Sridhar to the CC list)
Thanks for pointing out this inconsistency. It's not a big problem,
because on receiving EINTR or another error code, the app either
retries epoll_wait or, if the app is buggy somehow and doesn't retry
epoll_wait, the timer fires and everything proceeds as normal.
However, since irqs are not suspended at other points in ep_poll
where an error code is returned, it is probably best to be
consistent and not suspend here either. We will fix this in the next
revision.
Sridhar: Since the change is very minor I plan to retain your
Reviewed-by, but if you'd like me to drop it, please let me know.
The proposed fix will look like:
if (res) {
if (res > 0)
ep_suspend_napi_irqs(ep);
return res;
}
>
> > return res;
> > + }
> > }
> >
> > if (timed_out)
> > --
> > 2.25.1
Powered by blists - more mailing lists