From: David Howells <dhowells@redhat.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: dhowells@redhat.com, Al Viro <viro@zeniv.linux.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
"Christian Brauner" <christian@brauner.io>,
Matthew Wilcox <willy@infradead.org>,
"Brendan Higgins" <brendanhiggins@google.com>,
David Gow <davidgow@google.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"kunit-dev@googlegroups.com" <kunit-dev@googlegroups.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christian Brauner <brauner@kernel.org>,
David Hildenbrand <david@redhat.com>,
John Hubbard <jhubbard@nvidia.com>
Subject: Re: [RFC PATCH 9/9] iov_iter: Add benchmarking kunit tests for UBUF/IOVEC
Date: Fri, 15 Sep 2023 13:19:45 +0100 [thread overview]
Message-ID: <3545840.1694780385@warthog.procyon.org.uk> (raw)
In-Reply-To: <dcc6543d71524ac488ca2a56dd430118@AcuMS.aculab.com>
David Laight <David.Laight@ACULAB.COM> wrote:
> Isn't that going to be completely dominated by the cache fills
> from memory?
>
> I'd have thought you'd need to use something with a lot of
> small fragments so that the iteration code dominates the copy.
Okay, if I switch it to using MAP_ANON for the big 256MiB buffer, switch all
the benchmarking tests to use copy_from_iter() rather than copy_to_iter() and
make the iovec benchmark use a separate iovec for each page, there's then a
single page replicated across the mapping.
Given that, without my macro-to-inline-func patches applied, I see:
iov_kunit_benchmark_bvec: avg 3184 uS, stddev 16 uS
iov_kunit_benchmark_bvec: avg 3189 uS, stddev 17 uS
iov_kunit_benchmark_bvec: avg 3190 uS, stddev 16 uS
iov_kunit_benchmark_bvec_outofline: avg 3731 uS, stddev 10 uS
iov_kunit_benchmark_bvec_outofline: avg 3735 uS, stddev 10 uS
iov_kunit_benchmark_bvec_outofline: avg 3738 uS, stddev 11 uS
iov_kunit_benchmark_bvec_split: avg 3403 uS, stddev 10 uS
iov_kunit_benchmark_bvec_split: avg 3405 uS, stddev 18 uS
iov_kunit_benchmark_bvec_split: avg 3407 uS, stddev 29 uS
iov_kunit_benchmark_iovec: avg 6616 uS, stddev 20 uS
iov_kunit_benchmark_iovec: avg 6619 uS, stddev 22 uS
iov_kunit_benchmark_iovec: avg 6621 uS, stddev 46 uS
iov_kunit_benchmark_kvec: avg 2671 uS, stddev 12 uS
iov_kunit_benchmark_kvec: avg 2671 uS, stddev 13 uS
iov_kunit_benchmark_kvec: avg 2675 uS, stddev 12 uS
iov_kunit_benchmark_ubuf: avg 6191 uS, stddev 1946 uS
iov_kunit_benchmark_ubuf: avg 6418 uS, stddev 3263 uS
iov_kunit_benchmark_ubuf: avg 6443 uS, stddev 3275 uS
iov_kunit_benchmark_xarray: avg 3689 uS, stddev 5 uS
iov_kunit_benchmark_xarray: avg 3689 uS, stddev 6 uS
iov_kunit_benchmark_xarray: avg 3698 uS, stddev 22 uS
iov_kunit_benchmark_xarray_outofline: avg 4202 uS, stddev 3 uS
iov_kunit_benchmark_xarray_outofline: avg 4204 uS, stddev 9 uS
iov_kunit_benchmark_xarray_outofline: avg 4210 uS, stddev 9 uS
and with, I get:
iov_kunit_benchmark_bvec: avg 3241 uS, stddev 13 uS
iov_kunit_benchmark_bvec: avg 3245 uS, stddev 16 uS
iov_kunit_benchmark_bvec: avg 3248 uS, stddev 15 uS
iov_kunit_benchmark_bvec_outofline: avg 3705 uS, stddev 12 uS
iov_kunit_benchmark_bvec_outofline: avg 3706 uS, stddev 10 uS
iov_kunit_benchmark_bvec_outofline: avg 3709 uS, stddev 9 uS
iov_kunit_benchmark_bvec_split: avg 3446 uS, stddev 10 uS
iov_kunit_benchmark_bvec_split: avg 3447 uS, stddev 12 uS
iov_kunit_benchmark_bvec_split: avg 3448 uS, stddev 12 uS
iov_kunit_benchmark_iovec: avg 6587 uS, stddev 22 uS
iov_kunit_benchmark_iovec: avg 6587 uS, stddev 22 uS
iov_kunit_benchmark_iovec: avg 6590 uS, stddev 27 uS
iov_kunit_benchmark_kvec: avg 2671 uS, stddev 12 uS
iov_kunit_benchmark_kvec: avg 2672 uS, stddev 12 uS
iov_kunit_benchmark_kvec: avg 2676 uS, stddev 19 uS
iov_kunit_benchmark_ubuf: avg 6241 uS, stddev 2199 uS
iov_kunit_benchmark_ubuf: avg 6266 uS, stddev 2245 uS
iov_kunit_benchmark_ubuf: avg 6513 uS, stddev 3899 uS
iov_kunit_benchmark_xarray: avg 3695 uS, stddev 6 uS
iov_kunit_benchmark_xarray: avg 3695 uS, stddev 7 uS
iov_kunit_benchmark_xarray: avg 3703 uS, stddev 11 uS
iov_kunit_benchmark_xarray_outofline: avg 4215 uS, stddev 16 uS
iov_kunit_benchmark_xarray_outofline: avg 4217 uS, stddev 20 uS
iov_kunit_benchmark_xarray_outofline: avg 4224 uS, stddev 10 uS
Interestingly, most of them are quite tight, but UBUF is all over the place.
That's with the test covering the entire 256M span with a single UBUF
iterator, so it would seem unlikely that the difference is due to the
iteration framework.
David
prev parent reply other threads:[~2023-09-15 12:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 22:15 [RFC PATCH 0/9] iov_iter: kunit: Cleanup, abstraction and more tests David Howells
2023-09-14 22:15 ` [RFC PATCH 1/9] iov_iter: Fix some checkpatch complaints in kunit tests David Howells
2023-09-14 22:15 ` [RFC PATCH 2/9] iov_iter: Consolidate some of the repeated code into helpers David Howells
2023-09-14 22:15 ` [RFC PATCH 3/9] iov_iter: Consolidate the test vector struct in the kunit tests David Howells
2023-09-14 22:15 ` [RFC PATCH 4/9] iov_iter: Consolidate bvec pattern checking David Howells
2023-09-14 22:15 ` [RFC PATCH 5/9] iov_iter: Create a function to prepare userspace VM for UBUF/IOVEC tests David Howells
2023-09-14 22:15 ` [RFC PATCH 6/9] iov_iter: Add copy kunit tests for ITER_UBUF and ITER_IOVEC David Howells
2023-09-14 22:15 ` [RFC PATCH 7/9] iov_iter: Add extract " David Howells
2023-09-14 22:15 ` [RFC PATCH 8/9] iov_iter: Add benchmarking kunit tests David Howells
2023-09-14 22:15 ` [RFC PATCH 9/9] iov_iter: Add benchmarking kunit tests for UBUF/IOVEC David Howells
2023-09-15 7:09 ` David Laight
2023-09-15 10:10 ` David Howells
2023-09-15 10:51 ` David Laight
2023-09-15 11:23 ` David Howells
2023-09-15 12:10 ` David Laight
2023-09-15 12:36 ` David Howells
2023-09-15 13:08 ` David Laight
2023-09-15 13:24 ` David Howells
2023-09-15 12:19 ` David Howells [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=3545840.1694780385@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@linux-foundation.org \
--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=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=torvalds@linux-foundation.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 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.