From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Daniel P. Berrange" <berrange@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Cleber Rosa" <crosa@redhat.com>
Subject: Re: "make check-acceptance" takes way too long
Date: Tue, 15 Feb 2022 18:14:34 +0000 [thread overview]
Message-ID: <87ee44c7mp.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9cMZoj18gq7Ksv5PRoU1wRmXvW_e9UE73C_MEB7wTroQ@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> "make check-acceptance" takes way way too long. I just did a run
> on an arm-and-aarch64-targets-only debug build and it took over
> half an hour, and this despite it skipping or cancelling 26 out
> of 58 tests!
>
> I think that ~10 minutes runtime is reasonable. 30 is not;
> ideally no individual test would take more than a minute or so.
>
> Output saying where the time went. The first two tests take
> more than 10 minutes *each*. I think a good start would be to find
> a way of testing what they're testing that is less heavyweight.
>
> (01/58) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg_gicv2:
> PASS (629.74 s)
> (02/58) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_tcg_gicv3:
> PASS (628.75 s)
So I've done some digging and tried some alternative images but I'm
running into two things:
- -cpu max is slow without ,pauth-impdef=on
- for some reason the distro cloud images cause 2 orders of magnitude more TB
invalidates
For example a very simple Alpine boot:
Translation buffer state:
gen code size 810926227/1073659904
TB count 1514678
TB avg target size 17 max=2048 bytes
TB avg host size 292 bytes (expansion ratio: 16.8)
cross page TB count 0 (0%)
direct jump count 1035828 (68%) (2 jumps=772419 50%)
TB hash buckets 439751/524288 (83.88% head buckets used)
TB hash occupancy 42.96% avg chain occ. Histogram: [0,10)%|▄▁█▁▁▇▁▅▁▂|[90,100]%
TB hash avg chain 1.056 buckets. Histogram: 1|█▁ ▁▁|10
Statistics:
TB flush count 0
TB invalidate count 550632
TLB full flushes 0
TLB partial flushes 1488833
TLB elided flushes 12085180
[TCG profiler not compiled]
which unsurprisingly has this at the top of the perf profile:
20.17% qemu-system-aar qemu-system-aarch64 [.] do_tb_phys_invalidate
3.60% qemu-system-aar qemu-system-aarch64 [.] helper_lookup_tb_ptr
Versus my Debian Bullseye testing image (with all of systemd):
Translation buffer state:
gen code size 899208739/1073577984
TB count 1599725
TB avg target size 18 max=2048 bytes
TB avg host size 318 bytes (expansion ratio: 17.2)
cross page TB count 0 (0%)
direct jump count 1067312 (66%) (2 jumps=826284 51%)
TB hash buckets 816402/1048576 (77.86% head buckets used)
TB hash occupancy 36.57% avg chain occ. Histogram: [0,10)%|▅ █ ▆▁▃▁▂|[90,100]%
TB hash avg chain 1.027 buckets. Histogram: 1|█▁▁ ▁|9
Statistics:
TB flush count 0
TB invalidate count 7763
TLB full flushes 0
TLB partial flushes 1066791
TLB elided flushes 973569
[TCG profiler not compiled]
with a more reasonable balance:
4.21% qemu-system-aar qemu-system-aarch64 [.] get_phys_addr_lpae
4.16% qemu-system-aar qemu-system-aarch64 [.] helper_lookup_tb_ptr
I'm open to ideas as to what might cause that.
--
Alex Bennée
prev parent reply other threads:[~2022-02-15 18:36 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 15:12 "make check-acceptance" takes way too long Peter Maydell
2021-07-30 15:41 ` Philippe Mathieu-Daudé
2021-07-30 15:42 ` Peter Maydell
2021-07-30 22:04 ` Cleber Rosa
2021-07-31 6:39 ` Thomas Huth
2021-07-31 17:58 ` Cleber Rosa
2021-07-31 18:41 ` Alex Bennée
2021-07-31 20:32 ` Peter Maydell
2021-08-02 22:55 ` Cleber Rosa
2021-08-02 8:38 ` Daniel P. Berrangé
2021-08-02 12:47 ` Alex Bennée
2021-08-02 12:59 ` Daniel P. Berrangé
2021-08-02 12:55 ` Alex Bennée
2021-08-02 13:00 ` Peter Maydell
2021-08-02 13:04 ` Daniel P. Berrangé
2021-08-02 13:25 ` Thomas Huth
2021-08-02 13:00 ` Daniel P. Berrangé
2021-08-02 13:27 ` Thomas Huth
2021-08-02 13:43 ` Gerd Hoffmann
2022-01-20 15:13 ` Peter Maydell
2022-01-20 15:35 ` Philippe Mathieu-Daudé via
2022-01-21 7:56 ` Thomas Huth
2022-01-21 10:50 ` Markus Armbruster
2022-01-21 11:33 ` Peter Maydell
2022-01-21 12:23 ` Alex Bennée
2022-01-21 12:41 ` Thomas Huth
2022-01-21 15:21 ` Daniel P. Berrangé
2022-01-25 9:20 ` Gerd Hoffmann
2022-02-01 6:31 ` Stefano Brivio
2022-02-01 7:49 ` Gerd Hoffmann
2022-02-01 9:06 ` Daniel P. Berrangé
2022-02-01 10:27 ` Stefano Brivio
2022-02-01 11:17 ` Alex Bennée
2022-02-01 16:01 ` Cleber Rosa
2022-02-01 16:19 ` Daniel P. Berrangé
2022-02-01 17:47 ` Cleber Rosa
2022-02-01 18:03 ` Alex Bennée
2022-02-01 19:04 ` Cleber Rosa
2022-02-01 18:35 ` Stefano Brivio
2022-02-01 17:59 ` Cédric Le Goater
2022-02-01 11:06 ` Kashyap Chamarthy
2022-02-01 15:54 ` Cleber Rosa
2022-02-01 5:29 ` Cleber Rosa
2022-02-01 17:01 ` Daniel P. Berrangé
2022-02-01 17:59 ` Cleber Rosa
2022-02-15 18:14 ` Alex Bennée [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=87ee44c7mp.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=crosa@redhat.com \
--cc=f4bug@amsat.org \
--cc=peter.maydell@linaro.org \
--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 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.