I've seen this as well, and it slows EVERYTHING else down by running at much higher priority than the window manager. First thing I do, every time I run steam, is to change the niceness level back to 0 so that other things have a chance. At -10, if steam linux client gets to some buggy near infinite loop, everything else almost stops completely.

Ok, I researched a bit on the 'how' it is done, and it seems like steam is calling SDL_SetThreadPriority with SDL_THREAD_PRIORITY_HIGH which results in running at niceness level -10.

Still no idea as 'why', especially since as mentionned by @framingnoone running at much higher priority than the window manager (and Games!) can only cause issues. Should this be considered a bug?

The Steam client sets a few select threads to high priority as they are critical to it's event process and API support architecture. Those threads do not typically do long compute operations, but it is important that they are scheduled with as little delay as possible.

Nice level -10 is being set at process level, not thread level, and
frequently results in slow response of everything else on my system until I
reduce it to 0. There are no obvious ill effects to the stream client when
I do this. Before the client worked out how to make that change to nice -10
it happily ran at standard priority for many years.

On Mon, Nov 7, 2022, 10:13 AM TTimo @.***> wrote:

The Steam client sets a few select threads to high priority as they are
critical to it's event process and API support architecture. Those threads
do not typically do long compute operations, but it is important that they
are scheduled with as little delay as possible.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/8877#issuecomment-1305846598,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AELSBG35TC3IIIAG5XD7473WHETEHANCNFSM6AAAAAARTTBJ2Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

@framingnoone No it is effectively set at the thread level, but @TTimo what kind of processing steam is doing that requires running with a much higher priority than say gnome-shell? Or in other words, why running almost at the same priority than Pipewire/Pulseaudio? Because I could totally see it affecting the responsiveness of the system in a CPU restrained environment (apparently like @framingnoone's system is).

Noticing this as well, If the download & decompress process is impacted by this, it would explain why my system freezes during updates.

I really don't want to go have to configure another user for steam just to control its niceness.

The high priority threads are processing controller events which we want to deliver with low latency.

Having said that, there was a bug that caused us to incorrectly mark one of the UI threads as high priority instead of one of the controller threads. Note that this thread shouldn't have been doing any considerable CPU work, so I don't expect this to have a major impact on overall system responsiveness. But fixing that controller thread to have high priority might help with gamepad input latency in system under load.

Before:

[andres@andres-dev /mnt/p4/p4/quark/Steam/main]$ ps -Tl -p"$(pgrep -x steam)"  | grep -- -10
0 S  1000  185615  185615  184927  2  70 -10 - 225557 do_sys pts/4   00:00:03 steam  # <--- this is a steam UI thread, not the whole steam process
1 S  1000  185615  185720  184927  0  70 -10 - 225557 futex_ pts/4   00:00:00 Controller Work
1 S  1000  185615  185721  184927  0  70 -10 - 225557 hrtime pts/4   00:00:00 CSteamControlle

After:

[andres@andres-dev /mnt/p4/p4/quark/Steam/main]$ ps -Tl -p"$(pgrep -x steam)"  | grep -- -10
1 S  1000  201369  201997  201287  0  70 -10 - 229902 futex_ ?       00:00:00 Controller Work
1 S  1000  201369  201998  201287  0  70 -10 - 229902 hrtime ?       00:00:00 CSteamControlle
1 S  1000  201369  202024  201287  0  70 -10 - 229902 futex_ ?       00:00:00 GamepadUI Input

Thanks for the issue report.

@lostgoat Thanks I think what was happening was I was conflating this with the symptoms present in #6073. That problem seems to have nothing to do with the CPU though.

Cheers on the detailed report.

@lostgoat That makes sense, thank you for the details. As the bug has been resolved, and the question answered, I'll close the issue.

For the bonus question : the catch is that invoking sudo -u $USER does not preserve access to the dbus session, which is required by the SDL library to change the niceness to a negative value when the user does not otherwise have the permission to do so (usually by having a RLIMIT_NICE <= 20).