From: Shakeel Butt <shakeel.butt@linux.dev>
To: Usama Arif <usama.arif@linux.dev>
Cc: brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
d@ilvokhin.com, hannes@cmpxchg.org, riel@surriel.com,
kernel-team@meta.com
Subject: Re: [PATCH] eventpoll: compute timer slack lazily in ep_poll()
Date: Fri, 24 Jul 2026 09:20:13 -0700 [thread overview]
Message-ID: <amOQpfraUUmpJr2w@linux.dev> (raw)
In-Reply-To: <20260707190238.3478608-1-usama.arif@linux.dev>
On Tue, Jul 07, 2026 at 12:02:38PM -0700, Usama Arif wrote:
> ep_poll() computes the timer slack via select_estimate_accuracy() up front,
> before checking whether events are already available.
> select_estimate_accuracy() reads the clock (ktime_get_ts64()), and the
> resulting slack is only consumed by the schedule_hrtimeout_range() call on
> the blocking path.
>
> A busy poller such as an L7 proxy event loop calls epoll_wait() at a very
> high rate and often finds events already pending, returning via
> ep_try_send_events() without ever blocking. In that case the up-front
> slack estimation - including its clock read - is pure overhead. read_tsc()
> attributable to select_estimate_accuracy() sometimes shows up in perf profiles
> of such a workload via the epoll_wait() path.
>
> Move the slack estimation to the point where the thread is actually about
> to sleep. The timeout passed to ep_poll() is already an absolute deadline
> (ep_timeout_to_timespec()), so deferring the estimate does not change the
> wakeup time; taken closer to the sleep it is, if anything, marginally more
> accurate. On the common non-blocking path the clock read is skipped
> entirely.
>
> Measured on a host running a Meta production workload with the following
> bpftrace script:
>
> #!/usr/bin/bpftrace
> fentry:__x64_sys_epoll_wait,
> fentry:__x64_sys_epoll_pwait { @in[tid] = 1; }
> fexit:__x64_sys_epoll_wait,
> fexit:__x64_sys_epoll_pwait { delete(@in, tid); }
> fentry:select_estimate_accuracy /@in[tid]/ { @sea++; }
> fentry:schedule_hrtimeout_range /@in[tid]/ { @shr++; }
> interval:s:30 {
> printf("sea=%lld shr=%lld wasted=%lld (%d%%)\n",
> @sea, @shr, @sea - @shr, (@sea - @shr) * 100 / @sea);
> exit();
> }
>
> Over a 30s window:
>
> sea=3,587,704 shr=3,003,920 wasted=583,784 (16%)
>
> So ~16% of ep_poll invocations of select_estimate_accuracy have no
> consumer.
>
> Signed-off-by: Usama Arif <usama.arif@linux.dev>
Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
prev parent reply other threads:[~2026-07-24 16:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 19:02 Usama Arif
2026-07-23 8:52 ` Christian Brauner
2026-07-24 16:20 ` Shakeel Butt [this message]
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=amOQpfraUUmpJr2w@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=brauner@kernel.org \
--cc=d@ilvokhin.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@surriel.com \
--cc=usama.arif@linux.dev \
--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
Powered by JetHome