From: David Laight <david.laight.linux@gmail.com>
To: Jon Kohler <jon@nutanix.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
kvm@vger.kernel.org, virtualization@lists.linux.dev,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Borislav Petkov" <bp@alien8.de>,
"Sean Christopherson" <seanjc@google.com>
Subject: Re: [PATCH net-next] vhost: use "checked" versions of get_user() and put_user()
Date: Fri, 14 Nov 2025 18:54:24 +0000 [thread overview]
Message-ID: <20251114185424.354133ae@pumpkin> (raw)
In-Reply-To: <20251113005529.2494066-1-jon@nutanix.com>
On Wed, 12 Nov 2025 17:55:28 -0700
Jon Kohler <jon@nutanix.com> wrote:
> vhost_get_user and vhost_put_user leverage __get_user and __put_user,
> respectively, which were both added in 2016 by commit 6b1e6cc7855b
> ("vhost: new device IOTLB API"). In a heavy UDP transmit workload on a
> vhost-net backed tap device, these functions showed up as ~11.6% of
> samples in a flamegraph of the underlying vhost worker thread.
>
> Quoting Linus from [1]:
> Anyway, every single __get_user() call I looked at looked like
> historical garbage. [...] End result: I get the feeling that we
> should just do a global search-and-replace of the __get_user/
> __put_user users, replace them with plain get_user/put_user instead,
> and then fix up any fallout (eg the coco code).
>
> Switch to plain get_user/put_user in vhost, which results in a slight
> throughput speedup. get_user now about ~8.4% of samples in flamegraph.
>
> Basic iperf3 test on a Intel 5416S CPU with Ubuntu 25.10 guest:
> TX: taskset -c 2 iperf3 -c <rx_ip> -t 60 -p 5200 -b 0 -u -i 5
> RX: taskset -c 2 iperf3 -s -p 5200 -D
> Before: 6.08 Gbits/sec
> After: 6.32 Gbits/sec
>
> As to what drives the speedup, Sean's patch [2] explains:
> Use the normal, checked versions for get_user() and put_user() instead of
> the double-underscore versions that omit range checks, as the checked
> versions are actually measurably faster on modern CPUs (12%+ on Intel,
> 25%+ on AMD).
Is there an associated access_ok() that can also be removed?
David
next prev parent reply other threads:[~2025-11-14 18:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 0:55 [PATCH net-next] vhost: use "checked" versions of get_user() and put_user() Jon Kohler
2025-11-13 1:09 ` Jason Wang
2025-11-14 14:53 ` Jon Kohler
2025-11-14 17:48 ` Linus Torvalds
2025-11-14 19:08 ` David Laight
2025-11-14 20:48 ` Linus Torvalds
2025-11-14 21:38 ` David Laight
2025-11-17 4:32 ` Jason Wang
2025-11-17 17:34 ` Jon Kohler
2025-11-20 1:57 ` Jason Wang
2025-11-25 19:45 ` Jon Kohler
2025-11-26 6:04 ` Jason Wang
2025-11-26 10:25 ` Arnd Bergmann
2025-11-26 19:47 ` Jon Kohler
2025-11-26 19:58 ` Arnd Bergmann
2025-11-26 21:42 ` Jon Kohler
2025-11-26 21:45 ` Linus Torvalds
2025-11-27 2:58 ` Jon Kohler
2025-11-27 1:08 ` Jason Wang
2025-11-27 3:11 ` Jon Kohler
2025-11-27 6:31 ` Michael S. Tsirkin
2025-11-27 6:32 ` Michael S. Tsirkin
2025-12-02 16:54 ` Jon Kohler
2025-11-14 18:54 ` David Laight [this message]
2025-11-14 19:30 ` Jon Kohler
2025-11-14 20:32 ` David Laight
2025-11-16 6:32 ` Michael S. Tsirkin
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=20251114185424.354133ae@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=bp@alien8.de \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=jon@nutanix.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=seanjc@google.com \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.linux.dev \
/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.