Re: Ars claims: Fedora 32 is sluggish

[Ondrej Mosnacek]

On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov  wrote:
> On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro  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-with...
> >
> > "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-workstati...
> >
> > 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/73c86ebaee23df8310b903c1dab2176d...
> (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/9d69ad49ab90db607e25a99eacb...

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.

Ars claims: Fedora 32 is sluggish

[Peter Robinson]

On Thu, Feb 11, 2021 at 1:03 PM Ondrej Mosnacek  wrote:
> On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov  wrote:
> > On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro  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-with...
> > >
> > > "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-workstati...
> > >
> > > 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/73c86ebaee23df8310b903c1dab2176d...
> > (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/9d69ad49ab90db607e25a99eacb...
>
> 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] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...

Ars claims: Fedora 32 is sluggish

[Thorsten Leemhuis]

Am 11.02.21 um 15:28 schrieb Peter Robinson:
> On Thu, Feb 11, 2021 at 1:03 PM Ondrej Mosnacek  wrote:
> > On Thu, Feb 11, 2021 at 10:14 AM Viktor Ashirov  wrote:
> > > On Wed, Feb 3, 2021 at 5:54 PM Michael Catanzaro  wrote:
>
> […]
> > > 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:
>
> […]
> 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.

FWIW, I wonder if some changes that were merged for mainline this week
might be related:

https://git.kernel.org/torvalds/c/291009f656e8eaebbdfd3a8d99f6b190a9ce9deb
https://git.kernel.org/torvalds/c/d11a1d08a082a7dc0ada423d2b2e26e9b6f2525c
https://git.kernel.org/torvalds/c/3c55e94c0adea4a5389c4b80f6ae9927dd6a4501

But I'm not entirely sure what CPUs are affected by d11a1d08a082

HTH, CU, thl