On Thu, Feb 11, 2021 at 1:03 PM Ondrej Mosnacek <omosnace(a)redhat.com> wrote:
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?
It was upstream changes, the Intel maintainer changed it in [1] if
X86_INTEL_PSTATE state was selected in late March which would make
sense in the timg, and also changed for arm arches [2] in July.
If that change was made upstream I'm assuming it was assumed that
performance should be equivalent or better than the other option, I
suspect we should engage with upstream as they're probably interested
in the issues.
[1]