From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Howells <dhowells@redhat.com>
Cc: Christian Brauner <christian@brauner.io>,
Jens Axboe <axboe@kernel.dk>, Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@lst.de>,
David Laight <David.Laight@aculab.com>,
Matthew Wilcox <willy@infradead.org>,
Brendan Higgins <brendanhiggins@google.com>,
David Gow <davidgow@google.com>,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
linux-mm@kvack.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
linux-kernel@vger.kernel.org,
Christian Brauner <brauner@kernel.org>,
David Hildenbrand <david@redhat.com>,
John Hubbard <jhubbard@nvidia.com>
Subject: Re: [PATCH v3 08/10] iov_iter: Add benchmarking kunit tests
Date: Wed, 15 Nov 2023 11:28:22 -0500 [thread overview]
Message-ID: <CAHk-=wjytv+Gy-Ra0rhLCAW_120BvnzLC63tfkkZVXzGgD3_+w@mail.gmail.com> (raw)
In-Reply-To: <20231115154946.3933808-9-dhowells@redhat.com>
On Wed, 15 Nov 2023 at 10:50, David Howells <dhowells@redhat.com> wrote:
>
> Add kunit tests to benchmark 256MiB copies to a KVEC iterator, a BVEC
> iterator, an XARRAY iterator and to a loop that allocates 256-page BVECs
> and fills them in (similar to a maximal bio struct being set up).
I see *zero* advantage of doing this in the kernel as opposed to doing
this benchmarking in user space.
If you cannot see the performance difference due to some user space
interface costs, then the performance difference doesn't matter.
Yes, some of the cases may be harder to trigger than others.
iov_iter_xarray() isn't as common an op as ubuf/iovec/etc, but that
either means that it doesn't matter enough, or that maybe some more
filesystems could be taught to use it for splice or whatever.
Particularly for something like different versions of memcpy(), this
whole benchmarking would want
(a) profiles
(b) be run on many different machines
(c) be run repeatedly to get some idea of variance
and all of those only get *harder* to do with Kunit tests. In user
space? Just run the damn binary (ok, to get profiles you then have to
make sure you have the proper permission setup to get the kernel
profiles too, but a
echo 1 > /proc/sys/kernel/perf_event_paranoid
as root will do that for you without you having to then do the actual
profiling run as root)
Linus
next prev parent reply other threads:[~2023-11-15 16:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-15 15:49 [PATCH v3 00/10] iov_iter: kunit: Cleanup, abstraction and more tests David Howells
2023-11-15 15:49 ` [PATCH v3 01/10] iov_iter: Fix some checkpatch complaints in kunit tests David Howells
2023-11-16 4:00 ` Joe Perches
2023-11-15 15:49 ` [PATCH v3 02/10] iov_iter: Consolidate some of the repeated code into helpers David Howells
2023-11-15 15:49 ` [PATCH v3 03/10] iov_iter: Consolidate the test vector struct in the kunit tests David Howells
2023-11-15 15:49 ` [PATCH v3 04/10] iov_iter: Consolidate bvec pattern checking David Howells
2023-11-15 15:49 ` [PATCH v3 05/10] iov_iter: Create a function to prepare userspace VM for UBUF/IOVEC tests David Howells
2023-11-15 16:12 ` Linus Torvalds
2023-11-15 16:39 ` David Howells
2023-11-15 16:58 ` Linus Torvalds
2023-11-15 15:49 ` [PATCH v3 06/10] iov_iter: Add copy kunit tests for ITER_UBUF and ITER_IOVEC David Howells
2023-11-15 15:49 ` [PATCH v3 07/10] iov_iter: Add extract " David Howells
2023-11-15 15:49 ` [PATCH v3 08/10] iov_iter: Add benchmarking kunit tests David Howells
2023-11-15 16:28 ` Linus Torvalds [this message]
2023-11-15 15:49 ` [PATCH v3 09/10] iov_iter: Add kunit to benchmark decanting of xarray to bvec David Howells
2023-11-15 15:49 ` [PATCH v3 10/10] iov_iter: Add benchmarking kunit tests for UBUF/IOVEC David Howells
2023-11-15 16:04 ` [PATCH v3 00/10] iov_iter: kunit: Cleanup, abstraction and more tests Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2023-09-22 11:30 David Howells
2023-09-22 11:30 ` [PATCH v3 08/10] iov_iter: Add benchmarking kunit tests David Howells
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='CAHk-=wjytv+Gy-Ra0rhLCAW_120BvnzLC63tfkkZVXzGgD3_+w@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=David.Laight@aculab.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=brendanhiggins@google.com \
--cc=christian@brauner.io \
--cc=david@redhat.com \
--cc=davidgow@google.com \
--cc=dhowells@redhat.com \
--cc=hch@lst.de \
--cc=jhubbard@nvidia.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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