[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: One Priority Per Run Queue
From:       Warner Losh <imp () bsdimp ! com>
Date:       2017-03-29 21:18:53
Message-ID: CANCZdfogvSXzHT33JxzvZ+0h8BjRetM=-vkPjzhyNJgznPhAnQ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Mar 29, 2017 at 2:00 PM, Eric van Gyzen <vangyzen@freebsd.org> wrote:
> 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 sched_get_priority_max() [0] 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 at least 32 priorities for this policy." [1]
>
> I propose that we assign one priority per run queue:
>
>         https://reviews.freebsd.org/D10188
>
> 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 a tiny improvement
> in performance. [2]
>
> Please test the above change, especially if you have an interesting
> workload that might be sensitive to scheduler behavior.  If you already
> know this change would cause problems, please point me toward the details.
>
> Assigning 4 priorities per run queue also caused a recent portability
> issue in ZFS, although that was fixed by r314058.

How does this scheme prevent starvation of low priority processes? Or
rather, how will this change after this change.

Warner

> [0]
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/sched_get_priority_max.html
>
> [1]
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_04_01
>
> [2] http://www.vangyzen.net/FreeBSD/1ppq/1ppq.html
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]