On Wed, Mar 29, 2023, at 12:41, Helmut Grohne wrote:
> On Wed, Mar 29, 2023 at 11:58:24AM +0200, Emanuele Rocca wrote:
>
> Thanks for the report. Since I mainly use it on amd64, I am not affected
> by this change and seek feedback from Arnd and Johannes as they will be
> affected.
The machine I use has KVM support for 64-bit guests, so
I think you have this the wrong way around: If you run
the arm64 guest with TCG, I would expect to see the
same effect on an arm64 host and an x86 host.
> My initial reaction is that I am slightly opposed to changing this,
> because architectures tend to bump baselines and at some point arm64
> will likely have a baseline that is not met by cortex-a57. So the max
> value poses less maintenance cost on my side.
It will be a very long time before Debian/arm64 can
consider bumping the baseline, as the oldest Cortex-A53
and Cortex-A57 cores are only ten years old at this point,
and the Cortex-A53 is still the most popular core in
currently shipping SoCs, by a wide margin.
> Now this is two arguments (performance vs maintenance) and we need to
> strike a good balance.
The maintenance argument goes both ways I think: Having
the A57 or A53 as the baseline makes it easier when
a package accidentally relies on a feature of a later
core without doing a runtime feature check, so that
would favor using A57 over cpu=max. The advantage
of using cpu=max is normally that this enables additional
features to be used in the guest that may provide
better performance or security, and allow testing those
features.
I don't know why the system performs poorly with cpu=max,
this may be a known issue with one of the features this
enables, or it may be a bug in the kernel or in qemu
that we should fix.
I have no objections to changing the default to
cpu=cortex-a57 for non-KVM runs, but I think more
importantly we should
a) try to reproduce the behavior on an x86-64 host, and
b) figure out the underlying issue.
Arnd
