From: Jens Axboe <axboe@kernel.dk>
To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: [PATCHSET RFC v2 0/5] Add support for epoll min_wait
Date: Fri, 28 Oct 2022 15:43:20 -0600 [thread overview]
Message-ID: <20221028214325.13496-1-axboe@kernel.dk> (raw)
Hi,
tldr - we saw a 6-7% CPU reduction with this patch. See patch 4 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 5, patches 1-4 are really
just prep patches.
Sending this as an RFC to hash out 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. Not a lot of changes
since v1, but it was posted in the middle of the merge window. Hoping
to get some more discussion this time around, or at least some...
Also available here:
https://git.kernel.dk/cgit/linux-block/log/?h=epoll-min_ts
Since v1:
- Split patch 4 a bit, to make the meat of the changes smaller
- Get rid of EPOLL_DEF_MIN_WAIT
- Rebase on current -git master
--
Jens Axboe
next reply other threads:[~2022-10-28 21:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 21:43 Jens Axboe [this message]
2022-10-28 21:43 ` [PATCH 1/5] eventpoll: cleanup branches around sleeping for events Jens Axboe
2022-10-28 21:43 ` [PATCH 2/5] eventpoll: split out wait handling Jens Axboe
2022-10-28 21:43 ` [PATCH 3/5] eventpoll: move expires to epoll_wq Jens Axboe
2022-10-28 21:43 ` [PATCH 4/5] eventpoll: move file checking earlier for epoll_ctl() Jens Axboe
2022-10-28 21:43 ` [PATCH 5/5] eventpoll: add support for min-wait Jens Axboe
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=20221028214325.13496-1-axboe@kernel.dk \
--to=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 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).