linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@fomichev.me>
To: Joe Damato <jdamato@fastly.com>
Cc: netdev@vger.kernel.org, mkarsten@uwaterloo.ca,
	amritha.nambiar@intel.com, sridhar.samudrala@intel.com,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	"open list:FILESYSTEMS (VFS and infrastructure)"
	<linux-fsdevel@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC net-next 5/5] eventpoll: Control irq suspension for prefer_busy_poll
Date: Mon, 12 Aug 2024 13:20:49 -0700	[thread overview]
Message-ID: <ZrpuodWa6cKh0sPk@mini-arch> (raw)
In-Reply-To: <20240812125717.413108-6-jdamato@fastly.com>

On 08/12, Joe Damato wrote:
> From: Martin Karsten <mkarsten@uwaterloo.ca>
> 
> When events are reported to userland and prefer_busy_poll is set, irqs are
> temporarily suspended using napi_suspend_irqs.
> 
> If no events are found and ep_poll would go to sleep, irq suspension is
> cancelled using napi_resume_irqs.
> 
> Signed-off-by: Martin Karsten <mkarsten@uwaterloo.ca>
> Co-developed-by: Joe Damato <jdamato@fastly.com>
> Signed-off-by: Joe Damato <jdamato@fastly.com>
> Tested-by: Joe Damato <jdamato@fastly.com>
> Tested-by: Martin Karsten <mkarsten@uwaterloo.ca>
> ---
>  fs/eventpoll.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index cc47f72005ed..d74b5b9c1f51 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -457,6 +457,8 @@ static bool ep_busy_loop(struct eventpoll *ep, int nonblock)
>  		 * it back in when we have moved a socket with a valid NAPI
>  		 * ID onto the ready list.
>  		 */
> +		if (prefer_busy_poll)
> +			napi_resume_irqs(napi_id);
>  		ep->napi_id = 0;
>  		return false;
>  	}
> @@ -540,6 +542,14 @@ static long ep_eventpoll_bp_ioctl(struct file *file, unsigned int cmd,
>  	}
>  }
>  
> +static void ep_suspend_napi_irqs(struct eventpoll *ep)
> +{
> +	unsigned int napi_id = READ_ONCE(ep->napi_id);
> +
> +	if (napi_id >= MIN_NAPI_ID && READ_ONCE(ep->prefer_busy_poll))
> +		napi_suspend_irqs(napi_id);
> +}
> +
>  #else
>  
>  static inline bool ep_busy_loop(struct eventpoll *ep, int nonblock)
> @@ -557,6 +567,10 @@ static long ep_eventpoll_bp_ioctl(struct file *file, unsigned int cmd,
>  	return -EOPNOTSUPP;
>  }
>  
> +static void ep_suspend_napi_irqs(struct eventpoll *ep)
> +{
> +}
> +
>  #endif /* CONFIG_NET_RX_BUSY_POLL */
>  
>  /*
> @@ -788,6 +802,10 @@ static bool ep_refcount_dec_and_test(struct eventpoll *ep)
>  
>  static void ep_free(struct eventpoll *ep)
>  {
> +	unsigned int napi_id = READ_ONCE(ep->napi_id);
> +
> +	if (napi_id >= MIN_NAPI_ID && READ_ONCE(ep->prefer_busy_poll))
> +		napi_resume_irqs(napi_id);
>  	mutex_destroy(&ep->mtx);
>  	free_uid(ep->user);
>  	wakeup_source_unregister(ep->ws);
> @@ -2005,8 +2023,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);

Aren't we already doing defer in the busy_poll_stop? (or in napi_poll
when it's complete/done). Why do we need another rearming here?

  reply	other threads:[~2024-08-12 20:20 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-12 12:57 [RFC net-next 0/5] Suspend IRQs during preferred busy poll Joe Damato
2024-08-12 12:57 ` [RFC net-next 4/5] eventpoll: Trigger napi_busy_loop, if prefer_busy_poll is set Joe Damato
2024-08-12 13:19   ` Christoph Hellwig
2024-08-12 16:17     ` Matthew Wilcox
2024-08-12 17:49       ` Joe Damato
2024-08-12 17:46     ` Joe Damato
2024-08-12 12:57 ` [RFC net-next 5/5] eventpoll: Control irq suspension for prefer_busy_poll Joe Damato
2024-08-12 20:20   ` Stanislav Fomichev [this message]
2024-08-12 21:47     ` Martin Karsten
2024-08-12 20:19 ` [RFC net-next 0/5] Suspend IRQs during preferred busy poll Stanislav Fomichev
2024-08-12 21:46   ` Martin Karsten
2024-08-12 23:03     ` Stanislav Fomichev
2024-08-13  0:04       ` Martin Karsten
2024-08-13  1:54         ` Stanislav Fomichev
2024-08-13  2:35           ` Martin Karsten
2024-08-13  4:07             ` Stanislav Fomichev
2024-08-13 13:18               ` Martin Karsten
2024-08-14  3:16                 ` Willem de Bruijn
2024-08-14 14:19                   ` Joe Damato
2024-08-14 15:08                     ` Willem de Bruijn
2024-08-14 15:46                       ` Joe Damato
2024-08-14 19:53                 ` Samiullah Khawaja
2024-08-14 20:42                   ` Martin Karsten
2024-08-16 14:27                     ` Willem de Bruijn
2024-08-16 14:59                       ` Willem de Bruijn
2024-08-16 15:25                         ` Joe Damato
2024-08-16 17:01                           ` Willem de Bruijn
2024-08-16 20:03                             ` Martin Karsten
2024-08-16 20:58                               ` Willem de Bruijn
2024-08-17 18:15                                 ` Martin Karsten
2024-08-18 12:55                                   ` Willem de Bruijn
2024-08-18 14:51                                     ` Martin Karsten
2024-08-20  2:36                                       ` Jakub Kicinski
2024-08-20 14:28                                         ` Martin Karsten
2024-08-17 10:00                             ` Joe Damato
2024-08-14  0:10     ` Jakub Kicinski
2024-08-14  1:14       ` Martin Karsten
2024-08-20  2:07         ` Jakub Kicinski
2024-08-20 14:27           ` Martin Karsten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZrpuodWa6cKh0sPk@mini-arch \
    --to=sdf@fomichev.me \
    --cc=amritha.nambiar@intel.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=jdamato@fastly.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkarsten@uwaterloo.ca \
    --cc=netdev@vger.kernel.org \
    --cc=sridhar.samudrala@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).