On Sun, Jul 24, 2022 at 4:29 AM Richard W.M. Jones <rjones@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
