On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov <vashirov(a)redhat.com> wrote:
On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
>
> Hi,
>
> Has anybody investigated Jim Salter's claims that Fedora 32 is slow to
> launch applications? Recent article:
>
>
https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-w...
>
> "in my experience, Fedora 32 is noticeably, demonstrably more sluggish
> to launch applications than Ubuntu is in general."
>
> Original article:
>
>
https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workst...
>
> Would be good to know, for starters, whether this difference is real
> and measurable.
This was bugging me for a while. I also noticed that Fedora 32 is a bit slower than it
used to be. Compilation time of a project that I'm working on went from ~35-36 seconds
to ~47-48. At first I thought that it's just another round of CPU vulnerabilities
mitigations that introduced a performance drop. But after some digging I found that the
default CPU governor was switched from 'ondemand' to 'schedutil' in Fedora
kernel 5.9.7:
https://src.fedoraproject.org/rpms/kernel/c/73c86ebaee23df8310b903c1dab21...
(see configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL)
I switched it back using cpupower from kernel-tools:
$ sudo cpupower frequency-set --governor ondemand
And confirmed that my compilation time went back to the previous ~35 seconds.
In the end I switched the governor to 'performance' and shaved another 5 seconds.
And gnome-shell no longer feels sluggish, switching tabs in the browser is also instant.
To make the change permanent I used settings in /etc/sysconfig/cpupower and enabled
cpupower service:
$ sudo systemctl enable --now cpupower.service
The change of the default CPU governor looks pretty significant to me, but I couldn't
find any discussions about it.
CCing the Fedora kernel list and Justin. At the ARK tree level, the
change was introduced in this commit, with no explanation:
https://gitlab.com/cki-project/kernel-ark/commit/9d69ad49ab90db607e25a99e...
Justin, do you remember the reason for the change? Can/should it be reverted?
--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.