The Performance Impact From Different Arch Linux Kernel Flavors

[Linuxxx]

Yeah I wish that was true but I had the completely opposite experience. I was stuck on a i3 dualcore laptop with 4GB for a while a couple of years ago. On Windows I'd have multiple browser tabs, a bunch of different programs and even an instance of a game running which would easily heavily utilize the pagefile and it'd run pretty much fine. Obviously there'd be the occasional hang and the general sluggishness (thankfully I was swapping to an SSD) but I would never have it completely lock up. On Linux on the other hand I'd swap a couple of GB and it'd be game over. Most of the time it wouldn't even respond to my SysRq inputs, so I would have to hard reboot rather than hoping to manually invoke the oom daemon and in the worst case do a quick REISUB.

I do wonder how much the situation improved now with the introduction of MGLRU?

Classic example of using a non-lowlatency optimized Linux kernel flavor on the desktop...

Like the following user, you too might one day learn to switch to a proper one for interactivity:

I have this old laptop with dual AMD A6-4400M at 1600MHz, that I use sparingly when I'm out of the office, mainly to read email and browse casual web sites. There was something, possibly connected with software updates, which makes it unresponsive. Something like typing a dozen characters without seeing the first one. Often the widget asking whether I should force-quit a process.

After sudo apt-get install linux-lowlatency and reboot, it became smooth and responsive. (uname -r 5.0.0-20-lowlatency.) Wonderful, I should have switched years ago. Let me stress Seven's answer: unless you want to squeeze the max out of a number crunching server, go for the -preempt!

[Alexmitter]

System responsiveness, whilst hard to test, would be a good one.

Linux trashes Windows in nearly every non-GPU benchmark, but I bet you Windows stays more responsiveness than GNOME under CPU-pressure. I am curious whether the RT kernels would show any improvement here.

I remember that this was a thing, but it does not seem to be a issue anymore. All 24 threads stressed 100% and gnome still feels normal. The only thing that took quarter a second thinking time was opening the application list, overview and the rest works just fine on full pressure now.

Regular Fedora with the regular Fedora kernel.

[lumks]

Thats EndeavourOS, not Arch… Would you mark this as EndeavourOS tests, not as ArchLinux bait?

[Alexmitter]

Anything to back it up? No? Just what I thought. Starting with Windows Vista, the vast majority of UI rendering in Windows is done on GPU and Linux is nowhere near close.

Hey Birdie, Cairo's CPU path is often faster then 2D rasterizing on Windows with their semi-GPU acceleration. The rest is BS, The Windows Shell mostly runs on rasterization calls translated to GPU calls when possible while shells like Gnome purely use modern OpenGL drawing calls via Clutter. The only part of the Windows shell that get even close are the XAML UI based stuff that survived from Windows 8 like the start menu in Windows 10, this stuff is properly GPU rendered. Can't say it works better then its 2D predecessor in Windows 7.

[binarybanana]

Linux, I am not sure of much you can do to tell the kernel you prefer to keep the desktop responsive, other than add real time permissions to the process, make the OOM manager ignore it, use high-priority context on the GPU.. But, I am not aware of any mainstream distro and desktop that does all these and Linux is still unable to recover from GPU crashes, where as Windows can and completely rebuild the desktop (applications may crash, but the desktop survives)

In theory this can be done with cgroups. All you have to do is create a "desktop" cgroup for the display server, desktop/WM, etc. and give those a guaranteed share of CPU time and RAM. Or do the opposite and create a "other" group for non-desktop software with (soft) limits. There exists a package called cgroup-utils (IIRC) with a daemon that can automatically classify programs but it can be done manually, too. With cgroups it's also possible to freeze programs (like SIGSTOP) and flush all their memory to swap. Can be useful for keeping programs "running" ie the background without using any ressources.

Maybe there are some limitations I'm not aware of but in theory it seems quite doable. Of course, no user frindly interface for this exists.

[xpander]

It should be fixed as of a few hours ago, assuming your browser is getting the latest CSS, it should be inverted now.

It seems to be broken with Dark Reader extension also. Used to work fine like few weeks ago or so.

https://i.imgur.com/V3D5X6t.png

I

[guiodic]

maybe the hardware is new and therefore benefited from the latest kernel support.
LTS is still good for hardware with 2-years old or older.

I confirm. I tested Av1 encoding and speedometer on my not-so-old Intel tigerlake cpu and the difference is less than 1% (so in the error margin)

[yossarianuk]

Thats EndeavourOS, not Arch… Would you mark this as EndeavourOS tests, not as ArchLinux bait?

EndeavourOS uses Arch packages (it has its own themes and useful utilities but the system packages are directly from Arch) - its not like Manjaro

[Anux]

but I bet you Windows stays more responsiveness than GNOME under CPU-pressure.

I haven't used gnome for a while but considdering how slow and laggy Windows UI behaves that sounds highly unlikely. At least XFCE under Arch with the Zen Kernel leaves Windows far behind in the dust responsive wise.

[yossarianuk]

System responsiveness, whilst hard to test, would be a good one.

Linux trashes Windows in nearly every non-GPU benchmark, but I bet you Windows stays more responsiveness than GNOME under CPU-pressure. I am curious whether the RT kernels would show any improvement here.

Serves you right for not using KDE (which is more responsive than Windows)