Should Thread.Priority set nice on Linux?

[PJB3005]

Out of the box, Thread.Priority does nothing on Linux. This has been discussed in another issue: #60114. The core problem mentioned there is that Linux' default scheduler policy, SCHED_OTHER, ignores priority values. From the man page:

   For threads scheduled under one of the normal scheduling policies
   (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority is not
   used in scheduling decisions (it must be specified as 0).

Except, that's not the only way to influence CPU scheduling on Linux. You can also change the nice value:

   The nice value is an attribute that can be used to influence the
   CPU scheduler to favor or disfavor a process in scheduling
   decisions.  It affects the scheduling of SCHED_OTHER and
   SCHED_BATCH (see below) processes.  The nice value can be
   modified using nice(2), setpriority(2), or sched_setattr(2).

Now, nice values on Linux are not as absolute as Windows' thread priorities (according to the respective documentation), so I can understand that the behavior wouldn't be the same. But I do wonder if it makes sense to just map priority values to nice anyways?

[ghost]

Tagging subscribers to this area: @mangod9 See info in area-owners.md if you want to be subscribed.

Issue Details

---

Out of the box, `Thread.Priority` does nothing on Linux. This has been discussed in another issue: #60114. The core problem mentioned there is that Linux' default scheduler policy, `SCHED_OTHER`, ignores priority values. From [the man page](https://man7.org/linux/man-pages/man7/sched.7.html): For threads scheduled under one of the normal scheduling policies (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority is not used in scheduling decisions (it must be specified as 0). Except, that's not the only way to influence CPU scheduling on Linux. You can also change the `nice` value: The nice value is an attribute that can be used to influence the CPU scheduler to favor or disfavor a process in scheduling decisions. It affects the scheduling of SCHED_OTHER and SCHED_BATCH (see below) processes. The nice value can be modified using nice(2), setpriority(2), or sched_setattr(2). Now, nice values on Linux are not as absolute as Windows' thread priorities (according to the respective documentation), so I can understand that the behavior wouldn't be the same. But I do wonder if it makes sense to just map priority values to nice anyways?

Author:	PJB3005
Assignees:	-
Labels:	`area-System.Threading`, `untriaged`
Milestone:	-

[janvorli]

@PJB3005 thank you for bringing this up. I've been also recently thinking about trying setting the nice values for the priority of GC threads where we also keep them on the same level as other threads on Unix. Sounds like it would make sense for the case you've mentioned too. I am assigning this to myself.

[piju3]

Thread.Priority should definitely set nice, since that's what most developers will expect and it's the closest concept in Linux, even if it doesn't perfectly match Windows' priorities. The documentation does say "The scheduling algorithm used to determine the order of thread execution varies with each operating system."

If not, the documentation should at least warn that it does nothing on Linux. As it is right now it's just broken.

For what it's worth, the setpriority and getpriority POSIX calls actually do set the nice value, so it's not unreasonable to use that word.