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

[F.Ultra]

I don't use autogroup, it does not do anything for me. It's disabled on kernel level. But, I did some Pulse Audio tweaking/prioritizing and it seemed to help a lot. I don't seem to have random slowdowns any more. Thanks all the same!

what was the pulse audio tweaking? Where the hiccups only in the audio or was they also in the frametime?

[dimko]

what was the pulse audio tweaking? Where the hiccups only in the audio or was they also in the frametime?

deamon config

resample-method = speex-float-1
realtime-scheduling = yes
default-fragments = 2
default-fragment-size-msec = 4

i also start it with high priority

Frame time was also dropping bad.

[mdedetrich]

I tried pre-releases, with real time switching enabled. it hurt performance pretty bad in games.
Some serious frame drops happened. Will try release now...

This kind of behaviour is normal for RT kernels (although I don't know if its meant to be this extreme). People think RT is "magic" that doesn't have any drawbacks, but RT actually hurts raw performance. Generally speaking there is a tradeoff between latency (especially if its meant to be deterministic, i.e. having a roof which is the highest amount of latency expected) versus raw performance.

And games are all about raw performance, the last thing you want to have on a gaming machine is RT because the actual real time process'es can then interrupt the game process whenever they need a time slice from the CPU because they need to deterministically perform a task within a certain time window. Thats what RT is.

For a gaming machine you want the main gaming process to hog the resources from everything else, fundamentally opposed to RT.

[caligula]

This kind of behaviour is normal for RT kernels (although I don't know if its meant to be this extreme). People think RT is "magic" that doesn't have any drawbacks, but RT actually hurts raw performance. Generally speaking there is a tradeoff between latency (especially if its meant to be deterministic, i.e. having a roof which is the highest amount of latency expected) versus raw performance.

And games are all about raw performance, the last thing you want to have on a gaming machine is RT because the actual real time process'es can then interrupt the game process whenever they need a time slice from the CPU because they need to deterministically perform a task within a certain time window. Thats what RT is.

For a gaming machine you want the main gaming process to hog the resources from everything else, fundamentally opposed to RT.

People really expect to have it all. RT means that latency goes down to nanosecond scale. This means you can have analog like real music with gigahertz sample rate and 128 bit dynamics (maybe 512 bits with AVX512). You can compensate for any losses in perf by having more optimized kernel. -O6, funroll loops, BOLT, LTO, hand written AVX512, etc. If Linux ever wishes to be ready for desktop, it needs nanosecond latencies AND 2x - 3x the perf of Windows. IO_uring is a good starting point. IO_uring + NVMe PCI 5.0 storage in RAID0 striped over all free PCIe channels, with full support for zoned namespaces and other optimizations, IO folios, hard real time IO scheduler, LZ4 piped writes, something like 100 GB/s sustained writes and billions of IOPS are to be expected. 10 background compilations of kernel using make -j`nproc` in the background just for fun when playing most demanding AAA games in butter smooth zen state and multiple VRR 8k screens in 32 bit HDR 3d stereo mode. zstd optimized ZRAM optimizes the RAM from physical 256 GB to 512 GB virtual. String interning style reuse of memory pages. Transparent huge pages. There's so much Linux could do.

[caligula]

I increased my Wayland priority as well, as well as Pulseaudio. Hick ups were still there. Nothing else but gnome Wayland running in background on my linux Gentoo.

Um have you ever looked at process listings when using Gnome? Here are two obvious issues. PA -> PW. Try some lightweight compositor. Also switch from Network Damager to systemd-networkd. Gnome uses like 1,5 gigabytes of RAM when started. It starts like 300 processes. I'm looking at my laptop now after a fresh boot. 99 tasks, 368 threads, 292 kernel threads, 1,8 GB of RAM used.

[F.Ultra]

deamon config

resample-method = speex-float-1
realtime-scheduling = yes
default-fragments = 2
default-fragment-size-msec = 4

i also start it with high priority

Frame time was also dropping bad.

ok so you went from an audio buffer of 100ms to one of 8ms (if the previous values where the default values). I have no insight into how PA uses these values when it performs the mixing so have no idea why changing this removed frame time stuttering from the game, hypothesis is that with the larger buffer PA had to mix more data per iteration and if it run with realtime scheduling then it preemted the game when that happened leading to those frame time stutters. But that is an unsupported hypothesis at this time, just happy that the change made it work for you.

[skeevy420]

I was not particularly with good with description of my problem.

I have 32 core CPU(16 with hyper threading), games I play often don't even use half of that.
Yesterday I checked Fallout 4 with r12+, problem is that there is massive frame drop once every a few seconds. Hick up, if you like.
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. Nothing else but gnome Wayland running in background on my linux Gentoo.
Hardware wise, I seriously doubt there were bottle necks, like 50 processes you described. Nothing else was running on OS.
Non RT kernels don't have this issue. Hence I believe RT is doing something wrong.

I tried FIFO and Round Robin. I did not try deadline since I had some weird permission issues with it. Looks like sudo doesn't like it somehow.

I was exaggerating with the process count, but that point is valid nonetheless. When you have multiple real time processes, which is the most real time?

Then you have the issue of adjacent systems that aren't set as real time. For example, the game is running faster with real time but the Bluetooth daemon is regular priority. Now you have potential input lag due to the game taking precedence over the system receiving input commands. That's not ideal.

IMHO, you should try process isolation first and then real time second. I'm assuming that 32-core means 2 to 4 CCDs and the gaming lag inherent to that setup. Try limiting your game to 8 cores or less on a single CCD. RT or not, Multiple chiplets or not, not wrangling your game into the most optimal situation can cause gaming lag. Not having to do bullshit like that is why I game on a 7800X3D. The single CCD and only 8 cores means less wrangling of shit. At most I have to limit older Unity games, think KSP, to four cores.

Even if it's not CCD latency related, I was bored and reading random Wine/Proton posts and discussions the other day and you'd be surprised how many games just quit working with high core CPUs. Some games are like "You have 28 cores? Something fucky is going on...I don't think I'm gonna run now." The older the game, the more likely that scenario will happen.

If you're using Proton or a GE/TKG Wine you can set: "WINE_CPU_TOPOLOGY=8:0,1,2,3,4,5,6,7". That'll limit your game to the first 8 cores.

None of that covers potential game configuration issues. Bethesda games aren't very optimized by default. IIRC, Fallout 3/4/NV should be set to use 8 or less cores. 4 to 8 core CPUs were high end when they released. It's configured for single core by default. I assume you know this stuff, but just in case, you need to do some INI tweaks to set it up to use more cores. That video says to use your CPUs number of cores, but dude has a quad core. At most limit it to a single CCD, but I'd limit it to 8c/16t at most.

Wait, do you mean you have a 16 core CPU, 32 threads with hyperthreading? A 32 core CPU should have 64 hyperthreads.

[Quackdoc]

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)

scx scheds has been absolutely amazing for this, scx_rusty brought my average fps down to 56 from 60+, however when running aur updates It only ever drops down to 54fps at worst, and this is even when compiling a bunch of rust stuff which under normal cases brings me down to sub 20fps

Playing a game when compiling something is not a desktop thing.

AUR updates say hello

[jabl]

When you have multiple real time processes, which is the most real time?

The one with the highest priority, of course (assuming by "most real time" you mean "gets first dibs at running").

That being said, the real-time scheduling classes are a bit special, they're not some magic wroom-go-faster thing you can slap on some random process and expect things to go faster in general.

[skeevy420]

The one with the highest priority, of course (assuming by "most real time" you mean "gets first dibs at running").

Yep. When wine.exe, game.exe, and more are all set to use real time they can potentially fight and cause the problem that RT was expected to solve.

That being said, the real-time scheduling classes are a bit special, they're not some magic wroom-go-faster thing you can slap on some random process and expect things to go faster in general.

That's why, IMHO, the more interactive and graphical the system, the less it should be using real time and, instead, use niceness and process schedulers. Set it up so the game and Wine run with -15 and let CFS, BFQ, SCX, or ??? handle it.