On 7/6/2020 1:36 PM, Alexander Duyck wrote:
On Wed, Jun 24, 2020 at 4:03 PM Sridhar Samudrala <sridhar.samudrala@xxxxxxxxx> wrote:This patch triggers non-blocking busy poll when busy_poll is enabled, epoll is called with a timeout of 0 and is associated with a napi_id. This enables an app thread to go through napi poll routine once by calling epoll with a 0 timeout. poll/select with a 0 timeout behave in a similar manner. Signed-off-by: Sridhar Samudrala <sridhar.samudrala@xxxxxxxxx> v2: Added net_busy_loop_on() check (Eric) --- fs/eventpoll.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 12eebcdea9c8..c33cc98d3848 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1847,6 +1847,19 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, eavail = ep_events_available(ep); write_unlock_irq(&ep->lock); + /* + * Trigger non-blocking busy poll if timeout is 0 and there are + * no events available. Passing timed_out(1) to ep_busy_loop + * will make sure that busy polling is triggered only once. + */ + if (!eavail && net_busy_loop_on()) { + ep_busy_loop(ep, timed_out); + write_lock_irq(&ep->lock); + eavail = ep_events_available(ep); + write_unlock_irq(&ep->lock); + } + goto send_events; }Doesn't this create a scenario where the NAPI ID will not be disassociated if the polling fails? It seems like in order to keep parity with existing busy poll code you should need to check for !eavail after you release the lock and if that is true you should be calling ep_reset_busy_poll_napi_id so that you disassociate the NAPI ID from the eventpoll.
We are not going to sleep in this code path. I think napi id needs to be reset only if we are going to sleep and a wakeup is expected to set the nap_id again.
