Upgrading Ubuntu 22.04's Kernel & Mesa For Better AMD RDNA2 Performance

[skeevy420]

By the way - concerning unstable SW - any problems with Ubuntu 22.04 LTS due to systemd
and killing important processes due to freeing RAM (called out of memory [OOM] sevice ...
nice joke)? Was astonished to read this end of May ... 1st April is long gone.
Maybe no one is testing their flagship product at canonical - and why is such a service even
available for systemd?
* https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1972159
Maybe someone can give example where this may be helpful ... don't see any use on the desktop.
Even with 16 GB RAM this service is no help but a threat.

That's a systemd-oomd bug and effects Fedora and other distributions; not just Ubuntu. And it really isn't a bug; just a cruddy default.

Copy/pasted from Fedora

systemctl edit [email protected]
[Service]
ManagedOOMMemoryPressure=kill
ManagedOOMMemoryPressureLimit=10%

You could try changing 10% to 1%. Let yourself actually be OOM before OOMD kicks in.

IMHO, 10% isn't OOM. That's 3.2GB free on my system. Because I totally want Firefox killed off when I still have 3.2 gigs of ram

[JMB9]

That's a systemd-oomd bug and effects Fedora and other distributions; not just Ubuntu. And it really isn't a bug; just a cruddy default.

I am a Unix expert and RHCE ... so I would expect Fedora to try these things (and be rest assured:
THIS would never make it into RHEL!) ...
But Ubuntu was designed that the defaults are sane - as there is a high percentage of starters.
And this is a bug - you can not just kill PIDs deliberately. And it does not take hierarchy into account.
As it was reported that it kills shells ... so which idiots really made this on by default without testing
anything - or even programed it without reasonable strategies what to kill?
Normally one get fired for smaller problems like this one.
It is better to see a dying system and save the important bits than to kill a program which gets
heavy input - just for dev null.

I am using 16 GB RAM (and just for fun 16 GB Swap) ... so if I will experience something bad,
it is really trash.
Of cause I understand your argument - and killing Firefox was the 1st thing I thought about it
when starting to read your comment ... as a sane mean to get rid of such problems.
Firefox is really a nightmare concerning memory usage (maybe the part not written in Rust, I hope .
But this is - unfortunately - not the way it works. And even with Firefox you could work on
an important and complicated form and suddenly all your input is gone by the wind.
In such strange cases I just kill Firefox and restart it ... there is no need for a daemon doing this.

This is ok for Windows (and yes, there OOM would be a prised feature - but GNU/Linux users
should know better ...) - but this is absolutely a disaster for any GNU/Linux distro as these systems
were always reliable (if not using Wine - to get even Windows virus variants run).
But as said - Red Hat goes crazy - and I am still not knowing anyone doing real work under GNOME
and just smile if this is called "the Linux desktop" in some pseudo technical magazines.
And it is this misuse that I am not a friend of systemd - you could even start spying apps like on
smartphones ... and normally no one will look for the entire configuration with a looking glass.
Would need literally days ... maybe the reason I have not started with 24.04 LTS ...
With init scripts the (minimal) default was sane - you could edit something in a second
(with a little experience) - and now we have this beast.
Such a thing noticed to late would waste all the positive side effects of systemd - e.g.
boot time was no problem (for me) before systemd was used.
With the security problems it currently looks like it should be replaced - or at least
the development process should get new priorities than are applied currently.

So for Ubuntu such big bugs in a release LTS flagship product is worst which could
happen - it destroys trust (if this would still be there, of cause). This is not the Fedora toy project.
It is the same for pushing Wayland while it is not ready for people who has to get the job done ...
bugs, missing features, problems ... after so many years.
So the quality of coding and skill for release management seem to be really bad.
And it is ridiculous that the argument is: it must be the default so we get bug reports -
while at the same time no one is looking on bug reports.

And Linux is extremely old on current Ubuntu (LTS kernel were never reasonable for the desktop) -
and not (officially) moving till 22.04.2 ... Just inappropriate for the desktop using current graphic cards.
For the server this would be sane, though ... but if this is the setting for servers ...
Is OOM used on servers, too ??? Cough!
Maybe my next machine should have 64 GB ECC RAM ... :-)

[CochainComplex]

Not doing serious work on gnome? Gnome is the only wm where I can effectively use multi monitors with multiple workspaces in a quick manner. And than autotiling from system76 is pushing you into a perfect flow state

[skeevy420]

That's a lot to quote

systemd-oomd is from Fedora and this is part of the growing pains for it to go through before it makes it into RHEL. I've read the reports, Ubuntu and Fedora, and it is know to kill GNOME, i3, Firefox...To me, that shows that OOMD needs a "do not kill" list so the user can set a list of programs to not be killed regardless of the situation.

I don't disagree with most of the rest of what you posted.

In regards to init scripts and defaults -- there's a reason that "sticks to the default settings" Arch Linux doesn't benchmark very well -- The Linux kernel, programs, daemons, etc all come with settings that don't necessarily jive with each other. Here's a prime example using systemd's tmp.mount service and oomd. The first one, by default, uses 50% of your ram for /tmp directories and the 2nd one kills shit when you still have 10% free so using systemd, by default, without tuning a damn thing it means you really only have 40% of your memory available. If a person isn't like you or me then neither the ramdisk service nor the memory pressure service will be known to them.

[skeevy420]

Not doing serious work on gnome? Gnome is the only wm where I can effectively use multi monitors with multiple workspaces in a quick manner. And than autotiling from system76 is pushing you into a perfect flow state

In all fairness, on my 55" TV I can't get serious work done on GNOME. That's a lot of screen real-estate wasted by how GNOME does things and, to me, it's a real pain in the butt multitasking around GNOME when compared to other environments. If all I had open was a single window, sure. The second I'm dipping between an editor, terminal, calculator, browser, another editor, a music player, and another browser I get frustrated.

Yes, I sometimes run two web browsers at a time. Only MS Edge saves video progress on a couple of streaming sites I frequent.

[hax0r]

Wonder what regression in Linux 5.18 Git is making things slower for RDNA2 compared to 5.17

[skeevy420]

Wonder what regression in Linux 5.18 Git is making things slower for RDNA2 compared to 5.17

Serious Not Serious -- Ask Michael in a few more days

[Linuxxx]

That's a systemd-oomd bug and effects Fedora and other distributions; not just Ubuntu. And it really isn't a bug; just a cruddy default.

Copy/pasted from Fedora

systemctl edit [email protected]
[Service]
ManagedOOMMemoryPressure=kill
ManagedOOMMemoryPressureLimit=10%

You could try changing 10% to 1%. Let yourself actually be OOM before OOMD kicks in.

IMHO, 10% isn't OOM. That's 3.2GB free on my system. Because I totally want Firefox killed off when I still have 3.2 gigs of ram

At least Ubuntu/Canonical really does test things prior to release, unlike Fedora/RedHat:

This is greatly exasperated because systemd until v251 is using MemFree and not MemAvailable to decide how much memory is remaining. Since Linux aggressively uses MemFree for caching, this will result in systemd-oomd excessively killing applications.

There's a fix in upstream 030bc91cb98385904b28a839d1e04bb4160a52d2, which was released as v251 about a week ago.

Response from a Canonical developer:

We cherrypicked that patch in 22.04 before release

https://launchpad.net/ubuntu/+source...49.11-0ubuntu3

PS:
Really hope Your Mom gets well, soon.
Take good care of Her!

[nist]

In my opinion, the test Linux 5.17 - Mesa 22.0.1 is important to evaluate better the whole benchmark.

[sweetsuicide]

Hi,
I have a brand new Ubuntu 22.04 with a brand new RDNA2 graphics card. I am extremey sorry as I understand that this isn't the correct place for this.
I am having trouble following the instructions:
- Linux 5.17 is available as an HWE kernel on Ubuntu 22.04 . Tried it. It says I'm fine on 5.15. Is it the OEM variant? Because that doesn't sound like hwe to me
- OIBAF ppa. I already tried on an older laptop I have here, where I wanted to test galliumnine, but I always have the following issue:

The following NEW packages will be installed:
libllvm14 libllvm14:i386
The following packages have been kept back:
libegl-mesa0 libegl-mesa0:i386 libgbm1 libgbm1:i386 libgl1-mesa-dri
libgl1-mesa-dri:i386 libglapi-mesa libglapi-mesa:i386 libglx-mesa0
libglx-mesa0:i386
The following packages will be upgraded:
libdrm-amdgpu1 libdrm-amdgpu1:i386 libdrm-common libdrm-intel1
libdrm-intel1:i386 libdrm-nouveau2 libdrm-nouveau2:i386 libdrm-radeon1
libdrm-radeon1:i386 libdrm2 libdrm2:i386 libvdpau1 libxatracker2
mesa-va-drivers mesa-va-drivers:i386 mesa-vdpau-drivers mesa-vulkan-drivers
mesa-vulkan-drivers:i386 vdpau-driver-all

THE KEPT BACK PACKAGES will fuck up the whole stack. Only solution I found is remove and reinstall the whole GNOME STACK. Can someone help me out with this? How did you manage to install the packages without breaking everything?

Thank you