From: Alexander Monakov <amonakov@ispras.ru>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-devel@nongnu.org, mmromanov@ispras.ru
Subject: Re: [PATCH v4 00/10] Optimize buffer_is_zero
Date: Fri, 16 Feb 2024 02:37:46 +0300 (MSK) [thread overview]
Message-ID: <aa9996fb-a5f8-25aa-96dd-48e4797967e1@ispras.ru> (raw)
In-Reply-To: <2d211317-873e-43c6-a246-bd8bf84f048b@linaro.org>
On Thu, 15 Feb 2024, Richard Henderson wrote:
> > Converting a 4.4 GiB Windows 10 image to qcow2. It was mentioned in v1 and
> > v2,
> > are you saying they did not reach your inbox?
> > https://lore.kernel.org/qemu-devel/20231013155856.21475-1-mmromanov@ispras.ru/
> > https://lore.kernel.org/qemu-devel/20231027143704.7060-1-mmromanov@ispras.ru/
>
> I'm saying that this is not a reproducible description of methodology.
>
> With master, so with neither of our changes:
>
> I tried converting an 80G win7 image that I happened to have lying about, I
> see buffer_zero_avx2 with only 3.03% perf overhead. Then I tried truncating
> the image to 16G to see if having the entire image in ram would help -- not
> yet, still only 3.4% perf overhead. Finally, I truncated the image to 4G and
> saw 2.9% overhead.
>
> So... help be out here. I would like to be able to see results that are at
> least vaguely similar.
Ah, I guess you might be running at low perf_event_paranoid setting that
allows unprivileged sampling of kernel events? In our submissions the
percentage was for perf_event_paranoid=2, i.e. relative to Qemu only,
excluding kernel time under syscalls.
Retrieve IE11.Win7.VirtualBox.zip from
https://archive.org/details/ie11.win7.virtualbox
and use
unzip -p IE11.Win7.VirtualBox.zip | tar xv
to extract 'IE11 - Win7-disk001.vmdk'.
(Mikhail used a different image when preparing the patch)
On this image, I get 70% in buffer_zero_sse2 on a Sandy Bridge running
qemu-img convert 'IE11 - Win7-disk001.vmdk' -O qcow2 /tmp/t.qcow2
user:kernel time is about 0.15:2.3, so 70% relative to user time does
roughly correspond to single-digits percentage relative to (user+kernel) time.
(which does tell us that qemu-img is doing I/O inefficiently, it shouldn't
need two seconds to read a fully cached 5 Gigabyte file)
Alexander
next prev parent reply other threads:[~2024-02-15 23:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 8:14 [PATCH v4 00/10] Optimize buffer_is_zero Richard Henderson
2024-02-15 8:14 ` [PATCH v4 01/10] util/bufferiszero: Remove SSE4.1 variant Richard Henderson
2024-02-15 8:14 ` [PATCH v4 02/10] util/bufferiszero: Remove AVX512 variant Richard Henderson
2024-02-15 8:14 ` [PATCH v4 03/10] util/bufferiszero: Reorganize for early test for acceleration Richard Henderson
2024-02-15 8:14 ` [PATCH v4 04/10] util/bufferiszero: Remove useless prefetches Richard Henderson
2024-02-15 8:14 ` [PATCH v4 05/10] util/bufferiszero: Optimize SSE2 and AVX2 variants Richard Henderson
2024-02-15 8:14 ` [PATCH v4 06/10] util/bufferiszero: Improve scalar variant Richard Henderson
2024-02-15 8:14 ` [PATCH v4 07/10] util/bufferiszero: Introduce biz_accel_fn typedef Richard Henderson
2024-02-15 8:34 ` Philippe Mathieu-Daudé
2024-02-15 8:14 ` [PATCH v4 08/10] util/bufferiszero: Simplify test_buffer_is_zero_next_accel Richard Henderson
2024-02-15 8:40 ` Philippe Mathieu-Daudé
2024-02-15 8:14 ` [PATCH v4 09/10] util/bufferiszero: Add simd acceleration for aarch64 Richard Henderson
2024-02-15 8:47 ` Alexander Monakov
2024-02-15 17:47 ` Richard Henderson
2024-02-15 18:46 ` Alexander Monakov
2024-02-15 21:10 ` Richard Henderson
2024-02-15 8:14 ` [RFC PATCH v4 10/10] util/bufferiszero: Add sve " Richard Henderson
2024-02-16 9:33 ` Alex Bennée
2024-02-16 11:05 ` Alex Bennée
2024-02-15 8:57 ` [PATCH v4 00/10] Optimize buffer_is_zero Alexander Monakov
2024-02-15 21:16 ` Richard Henderson
2024-02-15 21:36 ` Alexander Monakov
2024-02-15 22:27 ` Richard Henderson
2024-02-15 23:37 ` Alexander Monakov [this message]
2024-02-16 8:11 ` Richard Henderson
2024-02-16 20:20 ` Alexander Monakov
2024-02-16 22:28 ` Richard Henderson
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=aa9996fb-a5f8-25aa-96dd-48e4797967e1@ispras.ru \
--to=amonakov@ispras.ru \
--cc=mmromanov@ispras.ru \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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;
as well as URLs for NNTP newsgroup(s).