Linux 6.12 Released With Real-Time Capabilities, Sched_Ext, More AMD RDNA4 & More

[cl333r]

I have 32 core CPU(16 with hyper threading), games I play often don't even use half of that.
I have 64 gig of ram and an SSD, I increased my Wayland priority as well, as well as Pulseaudio. Hick ups were still there.

I think you deserve a better PC, this one is pretty old and slow. When you buy a new one please don't throw this one to the landfill, I'll give it to a local charity for blind and deaf children from Afghanistan

[ahrs]

bloat



bloat



BLOAT

LoC only goes up, never goes down

unless planned obsolescence strikes and they remove yet another critical driver

Unlike the BSD kernels we have a novel concept called "Hardware support". I expect Linux will probably grow exponentially over time. Drivers aren't going to be removed if people are still left using and maintaining them.

[intelfx]

It's not supposed to hurt, right?

It is supposed to hurt.

RT is not a magic knob that makes everything go faster (or smoother). RT is a set of very specific kernel features that improves scheduling predictability (i.e. the chance of meeting a deadline) of those programs which are specifically carefully designed and written to take advantage of it. This improvement happens at the expense of slowing down everything else (in particular, slowing down all processes which are not designed to take advantage of RT, or those which do not need this predictability).

Games are not written to take advantage of RT, and neither are graphics drivers, compositors, or even the in-kernel DRM atomic modesetting subsystem (see the sibling thread about GNOME). Therefore, yes, it is supposed to hurt. Do not use RT unless you know exactly what (and why) you are doing.

[Kjell]

[...]I have 32 core CPU (16 with hyper threading) [...] Hick ups were still there

That's funny. I'm using the best hardware money can buy and problems you've described plagued my system for months

Nonetheless, I've managed to fix it. General gist is:

• Use a bleeding edge distro like Gentoo, Artix Linux or Arch Linux (mainly because gpu kernel modules, mesa/userspace and Compositor have interlinked logic which can cause stutters when one part is outdated)
• TKG Linux kernel has very good defaults, enable FULL PREEMPT and 1000Hz
• LAVD (sched_ext) is magical
• Install NTSYNC5
• Configure real time audio like groups/priority but most importantly look at kernel parameters, Arch Wiki can be useful
• Use MSI mode for AUDIO & GPU devices
• Use Wayland compositors based on Wlroots, or just KDE. E.g. Sway with max render time 0 for VRR to work.
• Enable VSYNC ingame and then use Mangohud to toggle driver's vsync presentation mode to MAILBOX_KHR. Do not use frame limiters or ingame frame caps with VRR and vsync. This works best in fullscreeen mode due to direct scanout
• Disable FIFO in amdgpu
• Use pstate for CPU and performance mode for your GPU, gamemoderun can automate this and temporarily disable laggy spinlock detection
• Do not use NVIDIA
• Edit: more pointers below https://www.phoronix.com/forums/foru...52#post1506552

Everything is buttersmooth and responsive with tuning. Good luck

[TNZfr]

Well, that's to be expected. Games don't need real time performance since they can spawn a lot of processes.
.../...

A lot of threads ... scheduling works on threads not on processes !

Reminder
Linux preemption modes available:
* Server
* Workstation
* Low latency
* Real time

Available preemption mechanism in Linux works in time-sharing mode instead of RT premption which works in real-time.

Time-sharing is lead by the kernel. It gives an amount of CPU time on each threads asking for CPU. This amount of CPU time is defined by the preemption mode. « Server » mode uses a long CPU time and « Low latency » the shortest. The CPU time used by preemption mode has an impact on context switch : short CPU time = more context switch.

Real Time preemption works differently. To free CPU, it's not a time parameter, it's :
* An other thread with higher priority is asking for CPU
* The current thread switches in wait mode (for an IO, a timer ... what ever)

To summurize, it's not a good idea to run back-office batches on a real time server.

When I tried RT preemption just for desktop environment (latest KDE Plasma), I noticed that graphic acceleration was not working. A kernel log study about this point should be done to try to understand why graphic acceleration doesn't like RT preemption.

[s_j_newbury]

The problem is clear, realtime systems prioritize running code. This is done in expense of I/O operations like loading data from disk. Those hickups likely appear because of the game expects the data to be available before the code needs it. This is not how RT works. The data will be fetched when asked, not before, not after. The code can continue after the data has been fetched. This leads to predictable handling of code and data and is exactly why applications on RT systems need to be written with RT in mind.

Done properly this can reduce or rather "produce" less or predictable latency for processes that need this. (like for example audio processors).

Applications that are not written for RT can produce unexpected behavior, crashes or completely hog the cpu, rendering everything else unusable.

The low latency kernel is perhaps what you need, which is not realtime, that you probably do not need at all.

Mostly agree with the above, except the PREEMPT_RT kernel should definitely not produce unexpected behaviour for non-rt processes, running random code with RT priority on the other hand can be problematic if it isn't well behaved. What it does do is break any long running kernel operation down into preemptable sub-operations which does reduce throughput because those kernel operations need to complete to make progress, it's like the other PREEMPT_* options but more extreme and needed quite a few changes to various subsystems to make it possible. It should always* improve worst case latency even for the non-rt case, but if you're waiting for IO you might be waiting longer. *except when the worst latency comes from the firmware!

[dimko]

That's funny. I'm using the best hardware money can buy and problems you've described plagued my system for months

Nonetheless, I've managed to fix it. General gist is:

• Use a bleeding edge distro like Gentoo, Artix Linux or Arch Linux (mainly because gpu kernel modules, mesa/userspace and Compositor have interlinked logic which can cause stutters when one part is outdated)
• TKG Linux kernel has very good defaults, enable FULL PREEMPT and 1000Hz
• LAVD (sched_ext) is magical
• Install NTSYNC5
• Configure real time audio like groups/priority but most importantly look at kernel parameters, Arch Wiki can be useful
• Use MSI mode for AUDIO & GPU devices
• Use Wayland compositors based on Wlroots, or just KDE. E.g. Sway with max render time 0 for VRR to work.
• Enable VSYNC ingame and then use Mangohud to toggle driver's vsync presentation mode to MAILBOX_KHR. Do not use frame limiters or ingame frame caps with VRR and vsync. This works best in fullscreeen mode due to direct scanout
• Disable FIFO in amdgpu
• Use pstate for CPU and performance mode for your GPU, gamemoderun can automate this and temporarily disable spinlock detection
• Do not use NVIDIA

Everything is buttersmooth and responsive with minor tuning. Good luck

I have been tweaking my set up.
I have played with pulseaudio settings and seemed to have dealt with hick ups.

whats this FIFO for AMD GPU driver?

And thanks for big reply. A lot of reading will have to be done.

[dimko]

I think you deserve a better PC, this one is pretty old and slow. When you buy a new one please don't throw this one to the landfill, I'll give it to a local charity for blind and deaf children from Afghanistan

Too bad for kids from Afghanistan, I shall upgrade my PC shortly and its already spoken for.
its AMD 3950X, so quite old...

[Kjell]

I have played with pulseaudio settings and seemed to have dealt with hick ups.

More pointers:

• Do not use Pulseaudio
• Use wireplumber pipewire-pulse pipewire-jack pipewire-alsa pipewire-audio to pipe all audio into pipewire
• realtime-privileges pkg has very sane defaults for realtime audio, make sure you're in right groups for wireplumber and pipewire
• Make sure you're using tsc=reliable kernel parameter for this to work, do not use hpet clock
• You might also want to try threadirqs kernel parameter if you're using PREEMPT FULL with Realtime Audio

whats this FIFO for AMD GPU driver?

gpu_sched.sched_policy=0

its AMD 3950X, so quite old...

Try pinning your game to specific cores which share the same CCX & CCD.

LAVD scheduler can be quite smart in this regard.

Also IRC old BIOS in dated Zen CPUs suffer from frame pacing due to fTPM module, disable it

[F.Ultra]

I was not very clear. I don't mind overall FPS drop. What I did want is increase in overall responsiveness and higher lower one percent. Also better priority handling, cause current one in Linux is pretty bad when comes to desktop.(for example, play game + compile something)

RT does barely nothing for those cases. Priority handling is the same with and without RT, a major change a while back is that nice values are only relative to other processes in the same autogroup so even if you set a higher priority to some task by giving it a less nice value, that nice/priority will only be relative to the other processes in the same autogroup and not against other processes in the system. Normally all processes launched from say the DE (gnome/kde) will be launched in the same autogroup but it you start something from a terminal then that might get their own autogroup so that is something to look out for (aka you might believe that you change the priority of a process but in reality you didn't).

The problem that you described in another post where you got small freezes every x seconds when running with RT enabled could very well be RT working as intended, aka at those intervals some other higher priority process wants to run and thanks to RT it could preempt your game inside that game processes quanta.