[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0UdD2cyikv8WgCoZSsHsxsbLm0-KZ9SxatbgEfgbb3z-FQ@mail.gmail.com>
Date: Mon, 6 Jul 2020 13:36:42 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Sridhar Samudrala <sridhar.samudrala@...el.com>
Cc: linux-fsdevel@...r.kernel.org, Netdev <netdev@...r.kernel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH v2] fs/epoll: Enable non-blocking busypoll when epoll
timeout is 0
On Wed, Jun 24, 2020 at 4:03 PM Sridhar Samudrala
<sridhar.samudrala@...el.com> 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@...el.com>
>
> 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.
Powered by blists - more mailing lists