Con Kolivas Fixes Up GUI-Related Stalls In Mesa

[raster]

It really, really wouldn't.

This patch, as I understand it, increases the priority of processes scheduled as the absolute lowest possible priority. Games do not fall into that category.

No - it changes the priority of THREADS that mesa creates - and this means anything that is using Mesa to render (your compositor, games, browsers these days etc.) can be affected as these are silent internal threads Mesa may be spinning off to do background work as a result of requests via regular OpenGL APIs etc. Mesa explicitly lowered the priority of these threads to IDLE so they don't impact other applications threads as much - that was already the case. This patch just lowers the priority less than before to a type (IDLE now BATCH) to where it gets more regular scheduling time, so they may now impact other threads more by taking time slices away, but may also provide results in a more timely fashion too. It depends on what the threads were/are doing and a whole host of other complex system state.

[puleglot]

That's interesting. After patching mesa-20.1.0_rc2, steam and firefox performs much better. Can anybody confirm that?

Update: it's radeonsi + I'm using hardware acceleration in both firefox and steam.

[TemplarGR]

That's interesting. After patching mesa-20.1.0_rc2, steam and firefox performs much better. Can anybody confirm that?

Update: it's radeonsi + I'm using hardware acceleration in both firefox and steam.

Radeonsi does seem to have lots of optimizations for Mesa 20.1 even without Kolivas's patch.

[puleglot]

Radeonsi does seem to have lots of optimizations for Mesa 20.1 even without Kolivas's patch.

Of course, I compared vanilla 20.1_rc2 and 20.1_rc2 with Kolivas's patch.

[Dr_ST]

For what is worths, in the past I encountered regular freezes using BFS + nvidia driver ... Not sure if this is related though, but this situation caused me to avoid BFS and MuQSS since then. I may give a shot one day when they'll be available in mainstream distribution.

[Zan Lynx]

I haven't looked into the rest of the Mesa code so I don't know why this might be so important. But I can guess.

There might be a limited pool of threads. Once all the thread pool is occupied by SCHED_IDLE threads no high priority threads can be added until they clear out.

Or it might be a memory pool. Maybe the idle thread is supposed to clean up unused objects but it isn't running. Then some high priority threads needs an object, but there's no room available until the idle thread cleans out the old ones.

Or any other kind of object. Perhaps the GPU has a limited number of textures or semaphores or something else.

It's almost certainly something similar to garbage collection in Java. Java runs fine without garbage collection. Right up to the point that it runs out of RAM. At that point everything stops until it has finished a full stop-the-world garbage collection cycle. So it is much better for the program performance if it runs a continuous series of small garbage collections at a low priority, but not such a low priority that it runs out of RAM.

[Zan Lynx]

Oh, and I bet why some people see the problem Con found, and other people don't, is the number of CPU threads available.

This latency thing is probably only found on CPUs like a 4c/4t Intel i5 or a 2c i3. I don't see many graphics output programs that use all 8 threads at 100% on an i7. With 8 CPU threads available there should be plenty of room to run a few SCHED_IDLE tasks.

Using Intel i7's, AMD Ryzens and Power9 64 thread CPUs is probably why I've never experienced the Wayland lag problems other people have reported. Mouse cursor freezes? Not for me.

But if I recall correctly Con Kolivas used to do a lot of testing on four core i5s for his scheduler work. Four cores was kind of an ideal point for his BFS.

[oiaohm]

Does make you wonder how many issues with latency is the scheduler vs the scheduler being told to-do X that is wrong.

[Guest]

Hm, I wonder if this will stop the desktop and Chrome from stuttering when I'm playing Warhammer.

[kcrudup]

Oh, and I bet why some people see the problem Con found, and other people don't, is the number of CPU threads available.

This is likely true- as I have an i7 running KDE (X11) with all the compositor bells and whistles, yet rarely saw stutters before the patch- but every now and then while building code (always multithreaded) opening a new konsole would have a stutter as the effects would launch. I'll have to run a test to be sure, but I'm pretty sure that doesn't happen now.