All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCHSET v3 0/5] Add support for epoll min_wait
Date: Wed, 2 Nov 2022 13:46:16 -0400	[thread overview]
Message-ID: <CA+FuTSfj5jn8Wui+az2BrcpDFYF5m5ehwLiswwHMPJ2MK+S_Jw@mail.gmail.com> (raw)
In-Reply-To: <20221030220203.31210-1-axboe@kernel.dk>

On Sun, Oct 30, 2022 at 6:02 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> Hi,
>
> tldr - we saw a 6-7% CPU reduction with this patch. See patch 6 for
> full numbers.
>
> This adds support for EPOLL_CTL_MIN_WAIT, which allows setting a minimum
> time that epoll_wait() should wait for events on a given epoll context.
> Some justification and numbers are in patch 6, patches 1-5 are really
> just prep patches or cleanups.
>
> Sending this out to get some input on the API, basically. This is
> obviously a per-context type of operation in this patchset, which isn't
> necessarily ideal for any use case. Questions to be debated:
>
> 1) Would we want this to be available through epoll_wait() directly?
>    That would allow this to be done on a per-epoll_wait() basis, rather
>    than be tied to the specific context.
>
> 2) If the answer to #1 is yes, would we still want EPOLL_CTL_MIN_WAIT?
>
> I think there are pros and cons to both, and perhaps the answer to both is
> "yes". There are some benefits to doing this at epoll setup time, for
> example - it nicely isolates it to that part rather than needing to be
> done dynamically everytime epoll_wait() is called. This also helps the
> application code, as it can turn off any busy'ness tracking based on if
> the setup accepted EPOLL_CTL_MIN_WAIT or not.
>
> Anyway, tossing this out there as it yielded quite good results in some
> initial testing, we're running more of it. Sending out a v3 now since
> someone reported that nonblock issue which is annoying. Hoping to get some
> more discussion this time around, or at least some...

My main question is whether the cycle gains justify the code
complexity and runtime cost in all other epoll paths.

Syscall overhead is quite dependent on architecture and things like KPTI.

Indeed, I was also wondering whether an extra timeout arg to
epoll_wait would give the same feature with less side effects. Then no
need for that new ctrl API.

  parent reply	other threads:[~2022-11-02 17:47 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-30 22:01 [PATCHSET v3 0/5] Add support for epoll min_wait Jens Axboe
2022-10-30 22:01 ` [PATCH 1/6] eventpoll: cleanup branches around sleeping for events Jens Axboe
2022-10-30 22:01 ` [PATCH 2/6] eventpoll: don't pass in 'timed_out' to ep_busy_loop() Jens Axboe
2022-10-30 22:02 ` [PATCH 3/6] eventpoll: split out wait handling Jens Axboe
2022-10-30 22:02 ` [PATCH 4/6] eventpoll: move expires to epoll_wq Jens Axboe
2022-10-30 22:02 ` [PATCH 5/6] eventpoll: move file checking earlier for epoll_ctl() Jens Axboe
2022-10-30 22:02 ` [PATCH 6/6] eventpoll: add support for min-wait Jens Axboe
2022-11-08 22:14   ` Soheil Hassas Yeganeh
2022-11-08 22:20     ` Jens Axboe
2022-11-08 22:25       ` Willem de Bruijn
2022-11-08 22:29         ` Jens Axboe
2022-11-08 22:44           ` Willem de Bruijn
2022-11-08 22:41       ` Soheil Hassas Yeganeh
2022-12-01 18:00       ` Jens Axboe
2022-12-01 18:39         ` Soheil Hassas Yeganeh
2022-12-01 18:41           ` Jens Axboe
2022-11-02 17:46 ` Willem de Bruijn [this message]
2022-11-02 17:54   ` [PATCHSET v3 0/5] Add support for epoll min_wait Jens Axboe
2022-11-02 23:09     ` Willem de Bruijn
2022-11-02 23:37       ` Jens Axboe
2022-11-02 23:51         ` Willem de Bruijn
2022-11-02 23:57           ` Jens Axboe
2022-11-05 17:39             ` Jens Axboe
2022-11-05 18:05               ` Willem de Bruijn
2022-11-05 18:46                 ` Jens Axboe
2022-11-07 13:25                   ` Willem de Bruijn
2022-11-07 14:19                     ` Jens Axboe
2022-11-07 10:10               ` David Laight
2022-11-07 20:56 ` Stefan Hajnoczi
2022-11-07 21:38   ` Jens Axboe
2022-11-08 14:00     ` Stefan Hajnoczi
2022-11-08 14:09       ` Jens Axboe
2022-11-08 16:10         ` Stefan Hajnoczi
2022-11-08 16:15           ` Jens Axboe
2022-11-08 17:24             ` Stefan Hajnoczi
2022-11-08 17:28               ` Jens Axboe
2022-11-08 20:29                 ` Stefan Hajnoczi
2022-11-09 10:09               ` David Laight
2022-11-10 10:13         ` Willem de Bruijn

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=CA+FuTSfj5jn8Wui+az2BrcpDFYF5m5ehwLiswwHMPJ2MK+S_Jw@mail.gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.