On Sun, Jul 24, 2022 at 4:29 AM Richard W.M. Jones <rjones(a)redhat.com> wrote:
The current Fedora Rawhide kernels are too slow to run libguestfs
tests when doing Koji builds. These run in a qemu VM, running the
Rawhide kernel, emulated using software virtualization (ie. TCG).
They now time out because these kernels are so slow. Until fairly
recently they were slow but working.
I wondered if particular debug options had a greater effect on
performance, so I compiled many kernels (v5.19-rc7 from upstream)
using the baseline "no debug" config, then adding each debug option
that we use in turn, and measuring the performance using [1], using
qemu software virtualization (TCG). The tests were run many times
with warmups discarded to get the mean and standard deviation, using
the hyperfine program[2].
The results are below, and not very conclusive, but some options do
have a very large performance impact.
NO_DEBUG is the kernel compiled with no debug options enabled (ie. the
baseline).
In the actual debug kernel I expect the slow downs to be multiplied
together. To test that I did an extra run with all debug options
enabled (ALL_DEBUG).
CONFIG_PROVE_LOCKING, CONFIG_LOCK_STAT and CONFIG_DEBUG_LOCK_ALLOC
were present and enabled in the kernel when it was imported into git
in 2010.
CONFIG_DEBUG_WW_MUTEX_SLOWPATH was turned off in the past
(RHBZ#1114160). It seems to have been switched on again in 2020.
CONFIG_DEBUG_KMEMLEAK seems like it was enabled in 2012.
It's also possible that an existing debug option has got slower in the
upstream kernel, that is, it's not that we've recently changed
something in Fedora.
Just to reiterate this is not being dropped. I did a bit of research,
CONFIG_DEBUG_WW_MUTEX_SLOWPATH was actually turned back on in 2018, as
upstream changed PROVE_LOCKING to select it. As such, there is no way
to turn it off without turning off PROVE_LOCKING. All things
considered, PROVE_LOCKING has found a good number of bugs over the
years. From the numbers you have given, there doesn't seem to be a
whole lot of opportunity for real improvement without turning off that
chain. Overall, this requires some thought on the rawhide debug
strategy more than anything else. We do have things (CKI and
similar) which can give us more useful data without making a debug
kernel default, but it still doesn't catch issues seen in hardware
drivers so much. Though if debug kernels have gotten slow enough that
no one is running them anymore, opting for the no-debug repo, we may
be better served by changing our strategy here.
Justin