From: David Laight <david.laight.linux@gmail•com>
To: Dave Hansen <dave.hansen@intel•com>
Cc: Kuniyuki Iwashima <kuniyu@google•com>,
alex@ghiti•fr, aou@eecs•berkeley.edu, axboe@kernel•dk,
bp@alien8•de, brauner@kernel•org, catalin.marinas@arm•com,
christophe.leroy@csgroup•eu, dave.hansen@linux•intel.com,
edumazet@google•com, hpa@zytor•com, kuni1840@gmail•com,
linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org, linux-riscv@lists•infradead.org,
linuxppc-dev@lists•ozlabs.org, maddy@linux•ibm.com,
mingo@redhat•com, mpe@ellerman•id.au, npiggin@gmail•com,
palmer@dabbelt•com, pjw@kernel•org, tglx@linutronix•de,
torvalds@linux-foundation•org, will@kernel•org, x86@kernel•org
Subject: Re: [PATCH v1 2/2] epoll: Use __user_write_access_begin() and unsafe_put_user() in epoll_put_uevent().
Date: Fri, 24 Oct 2025 15:47:15 +0100 [thread overview]
Message-ID: <20251024154715.577258ef@pumpkin> (raw)
In-Reply-To: <ea7552f1-842c-4bb8-b19e-0410bf18c305@intel.com>
On Fri, 24 Oct 2025 07:05:50 -0700
Dave Hansen <dave.hansen@intel•com> wrote:
> On 10/23/25 22:16, Kuniyuki Iwashima wrote:
> >> This makes me nervous. The access_ok() check is quite a distance away.
> >> I'd kinda want to see some performance numbers before doing this. Is
> >> removing a single access_ok() even measurable?
> > I noticed I made a typo in commit message, s/tcp_rr/udp_rr/.
> >
> > epoll_put_uevent() can be called multiple times in a single
> > epoll_wait(), and we can see 1.7% more pps on UDP even when
> > 1 thread has 1000 sockets only:
> >
> > server: $ udp_rr --nolog -6 -F 1000 -T 1 -l 3600
> > client: $ udp_rr --nolog -6 -F 1000 -T 256 -l 3600 -c -H $SERVER
> > server: $ nstat > /dev/null; sleep 10; nstat | grep -i udp
> >
> > Without patch (2 stac/clac):
> > Udp6InDatagrams 2205209 0.0
> >
> > With patch (1 stac/clac):
> > Udp6InDatagrams 2242602 0.0
>
> I'm totally with you about removing a stac/clac:
>
> https://lore.kernel.org/lkml/20250228203722.CAEB63AC@davehans-spike.ostc.intel.com/
>
> The thing I'm worried about is having the access_ok() so distant
> from the unsafe_put_user(). I'm wondering if this:
>
> - __user_write_access_begin(uevent, sizeof(*uevent));
> + if (!user_write_access_begin(uevent, sizeof(*uevent))
> + return NULL;
> unsafe_put_user(revents, &uevent->events, efault);
> unsafe_put_user(data, &uevent->data, efault);
> user_access_end();
>
> is measurably slower than what was in your series. If it is
> not measurably slower, then the series gets simpler because it
> does not need to refactor user_write_access_begin(). It also ends
> up more obviously correct because the access check is closer to
> the unsafe_put_user() calls.
>
> Also, the extra access_ok() is *much* cheaper than stac/clac.
access_ok() does contain a conditional branch
- just waiting for the misprediction penalty (say 20 clocks).
OTOH you shouldn't get that more that twice for the loop.
I'm pretty sure access_ok() itself contains an lfence - needed for reads.
But that ought to be absent from user_write_access_begin().
The 'masked' version uses alu operations (on x86-64) and don't need
lfence (or anything else) and don't contain a mispredictable branch.
They should be faster than the above - unless the code has serious
register pressure and too much gets spilled to stack.
The timings may also depend on the cpu you are using.
I'm sure I remember some of the very recent ones having much faster
stac/clac and/or lfence.
David
>
next prev parent reply other threads:[~2025-10-24 14:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 0:04 [PATCH v1 0/2] epoll: Save one stac/clac pair in epoll_put_uevent() Kuniyuki Iwashima
2025-10-23 0:04 ` [PATCH v1 1/2] uaccess: Add __user_write_access_begin() Kuniyuki Iwashima
2025-10-23 5:37 ` Linus Torvalds
2025-10-23 8:29 ` David Laight
2025-10-24 5:31 ` Kuniyuki Iwashima
2025-10-23 0:04 ` [PATCH v1 2/2] epoll: Use __user_write_access_begin() and unsafe_put_user() in epoll_put_uevent() Kuniyuki Iwashima
2025-10-23 19:40 ` Dave Hansen
2025-10-24 5:16 ` Kuniyuki Iwashima
2025-10-24 14:05 ` Dave Hansen
2025-10-24 14:47 ` David Laight [this message]
2025-10-28 5:32 ` Kuniyuki Iwashima
2025-10-28 9:54 ` David Laight
2025-10-28 16:42 ` Kuniyuki Iwashima
2025-10-28 16:58 ` Linus Torvalds
2025-10-29 1:42 ` Andrew Cooper
2025-10-28 22:30 ` David Laight
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=20251024154715.577258ef@pumpkin \
--to=david.laight.linux@gmail$(echo .)com \
--cc=alex@ghiti$(echo .)fr \
--cc=aou@eecs$(echo .)berkeley.edu \
--cc=axboe@kernel$(echo .)dk \
--cc=bp@alien8$(echo .)de \
--cc=brauner@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=christophe.leroy@csgroup$(echo .)eu \
--cc=dave.hansen@intel$(echo .)com \
--cc=dave.hansen@linux$(echo .)intel.com \
--cc=edumazet@google$(echo .)com \
--cc=hpa@zytor$(echo .)com \
--cc=kuni1840@gmail$(echo .)com \
--cc=kuniyu@google$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-riscv@lists$(echo .)infradead.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=maddy@linux$(echo .)ibm.com \
--cc=mingo@redhat$(echo .)com \
--cc=mpe@ellerman$(echo .)id.au \
--cc=npiggin@gmail$(echo .)com \
--cc=palmer@dabbelt$(echo .)com \
--cc=pjw@kernel$(echo .)org \
--cc=tglx@linutronix$(echo .)de \
--cc=torvalds@linux-foundation$(echo .)org \
--cc=will@kernel$(echo .)org \
--cc=x86@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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