Change Details

The FreeBSD schedulers assign four priorities to each run queue, making those priorities effectively equal. This breaks POSIX real-time priorities. Applications that use real-time scheduling use `sched_get_priority_min()` and [[ http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_get_priority_max.html | `sched_get_priority_max()` ]] to determine the available range of priorities, and then use simple arithmetic to assign relatively higher or lower priorities. If an application configures two threads with priorities `max` and `max-1` (for example), POSIX says the thread at priority `max` must be chosen if it is runnable. Since our implementation puts these two priorities in the same run queue, it may choose either thread, so it does not conform. The above functions currently return 0 and 31, respectively. One solution would change `...max()` to return 7 and change other code to translate the 8 POSIX values into the 32 FreeBSD values. However, this would also not conform, because "conforming implementations shall provide a priority range of [[ http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_04_01 | at least 32 priorities ]] for this policy." I propose that we assign one priority per run queue. This would conform to POSIX. On a certain commercial block storage product, this change made no difference in performance. Benchmarks of buildworld on two different machines actually showed [[ http://www.vangyzen.net/FreeBSD/1ppq/1ppq.html | a tiny improvement in performance ]]. Assigning 4 priorities per run queue also caused a recent portability issue in ZFS, although that was fixed by [[ https://svnweb.freebsd.org/base?view=revision&revision=r314058 | r314058 ]].

The FreeBSD schedulers assign four priorities to each run queue, making those priorities effectively equal. This breaks the POSIX real-time priority API. Applications that use real-time scheduling use `sched_get_priority_min()` and [[ http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_get_priority_max.html | `sched_get_priority_max()` ]] to determine the available range of priorities, and then use simple arithmetic to assign relatively higher or lower priorities. If an application configures two threads with priorities `max` and `max-1` (for example), POSIX says the thread at priority `max` must be chosen if it is runnable. Since our implementation puts these two priorities in the same run queue, it may choose either thread, so it does not conform. The above functions currently return 0 and 31, respectively. One solution would change `...max()` to return 7 and change other code to translate the 8 POSIX values into the 32 FreeBSD values. However, this would also not conform, because "conforming implementations shall provide a priority range of [[ http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_04_01 | at least 32 priorities ]] for this policy." I propose that we assign one priority per run queue. This would conform to POSIX. On a certain commercial block storage product, this change made no difference in performance. Benchmarks of buildworld on two different machines actually showed [[ http://www.vangyzen.net/FreeBSD/1ppq/1ppq.html | a tiny improvement in performance ]]. Assigning 4 priorities per run queue also caused a recent portability issue in ZFS, although that was fixed by [[ https://svnweb.freebsd.org/base?view=revision&revision=r314058 | r314058 ]].

The FreeBSD schedulers assign four priorities to each run queue, making those priorities effectively equal. This breaks the POSIX real-time prioritiesy API. Applications that use real-time scheduling use `sched_get_priority_min()` and [[ http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_get_priority_max.html | `sched_get_priority_max()` ]] to determine the available range of priorities, and then use simple arithmetic to assign relatively higher or lower priorities. If an application configures two threads with priorities `max` and `max-1` (for example), POSIX says the thread at priority `max` must be chosen if it is runnable. Since our implementation puts these two priorities in the same run queue, it may choose either thread, so it does not conform. The above functions currently return 0 and 31, respectively. One solution would change `...max()` to return 7 and change other code to translate the 8 POSIX values into the 32 FreeBSD values. However, this would also not conform, because "conforming implementations shall provide a priority range of [[ http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_04_01 | at least 32 priorities ]] for this policy." I propose that we assign one priority per run queue. This would conform to POSIX. On a certain commercial block storage product, this change made no difference in performance. Benchmarks of buildworld on two different machines actually showed [[ http://www.vangyzen.net/FreeBSD/1ppq/1ppq.html | a tiny improvement in performance ]]. Assigning 4 priorities per run queue also caused a recent portability issue in ZFS, although that was fixed by [[ https://svnweb.freebsd.org/base?view=revision&revision=r314058 | r314058 ]].