2.1 KiB
← Back to Twitter thread index
title: "Linux by default doesn't allow any increase in scheduling priority. Users need t" author: "NOTimothyLottes" handle: "@NOTimothyLottes" post_url: "https://x.com/NOTimothyLottes/status/2072135292115427728" post_id: "2072135292115427728" timestamp: "2026-07-01 01:48:46" post_count: 6 reply_count: 1 repost_count: 0 like_count: 3 view_count: 381
@NOTimothyLottes — Linux by default doesn't allow any increase in scheduling priority. Users need t
Post 1 (2026-07-01 01:45:40)
Working on the portable thread scheduling priority interface. Windows is a bit nicer by default, one can increase the scheduling priority without admin and there is a AvSetMmThreadCharacteristics() / AvSetMmThreadPriority() hack for "Pro Audio" scheduling needs.
Post 2 (2026-07-01 01:48:46) — reply to Post 1
Linux by default doesn't allow any increase in scheduling priority. Users need to manually setup special user|group with elevated rights. Also system calls that try elevated scheduling don't clamp, instead they fail -EPREM if out of bounds. So all around a pain in the ass.
Post 3 (2026-07-01 01:51:56) — reply to Post 2
I'm a little lazy right now and don't feel like trying SteamOS big picture mode to see what the default ulimits are. Curious what they allow.
Post 4 (2026-07-01 02:36:48) — reply to Post 3
Linux priority workarounds (a.) Use getrlimit() to get {soft,hard} limits (b.) Use setrlimit() to set 'soft=hard' limit (c.) Then set priority or nice based on new soft limit
Post 5 (2026-07-01 02:38:20) — reply to Post 4
I don't do one-time global priority maximums, just in case someone sudo's higher priority hard limit dynamically it should pickup the new limit.
Post 6 (2026-07-01 02:46:03) — reply to Post 5
Also while on setrlimit, I also bump up the RLIMIT_MEMLOCK to it's maximum just in case before the mlockall().
