[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj7s3VKFP2vLmEHhHZ=VBkr5v8J-Y47uzidnt=Kt+dzng@mail.gmail.com>
Date: Tue, 28 Oct 2025 12:02:33 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kuniyuki Iwashima <kuniyu@...gle.com>
Cc: Christian Brauner <brauner@...nel.org>, Jens Axboe <axboe@...nel.dk>,
Dave Hansen <dave.hansen@...ux.intel.com>, David Laight <david.laight.linux@...il.com>,
Eric Dumazet <edumazet@...gle.com>, Kuniyuki Iwashima <kuni1840@...il.com>, linux-kernel@...r.kernel.org,
Dave Hansen <dave.hansen@...el.com>
Subject: Re: [PATCH v2] epoll: Use user_write_access_begin() and
unsafe_put_user() in epoll_put_uevent().
On Tue, 28 Oct 2025 at 10:56, Kuniyuki Iwashima <kuniyu@...gle.com> wrote:
>
> Let's use user_write_access_begin() and unsafe_put_user() in
> epoll_put_uevent().
>
> We saw 2% more pps with udp_rr by saving a stac/clac pair.
This patch looks fine to me. Simple and targeted.
> Another option would be to use can_do_masked_user_access()
> and masked_user_access_begin(), but we saw 3% regression. (See Link)
So I find this intriguing, because generally,
masked_user_access_begin() should _never_ be slower than
user_write_access_begin().
user_write_access_begin() ends up doing a __uaccess_begin_nospec() on
x86, which is not just the STAC instruction, but also a barrier.
In contrast, masked_user_access_begin() obviously also has the STAC,
but it avoids the barrier and only uses a simple conditional mask.
So I get the feeling that you did something wrong. In particular,
following your link, I see you describe that case (2) as
2) masked_user_access_begin() + masked_user_access_begin()
97% pps compared to 1).
96% calls of ep_try_send_events().
and you mention masked_user_access_begin() *twice*.
Which would certainly explain why it's slower.
Can you show what the patch you used is?
Because I think the proper patch should look something like the
attached.. For me, that generates
movabs $0x123456789abcdef,%rcx
cmp %rcx,%r15
cmova %rcx,%r15
stac
mov %r12d,(%r15)
mov %rax,0x4(%r15)
clac
which honestly should be pretty much optimal.
(That 0x123456789abcdef is just a placeholder for the USER_PTR_MAX
value - it gets rewritten at boot to the right value).
NOTE! The attached patch has absolutely not been tested. I only used
it to verify the code generation visually, so you should definitely
check it yourself.
Linus
View attachment "patch.diff" of type "text/x-patch" (875 bytes)
Powered by blists - more mailing lists