Date: Wed, 29 Mar 2017 15:18:53 -0600 From: Warner Losh <imp@bsdimp.com> To: Eric van Gyzen <vangyzen@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: One Priority Per Run Queue Message-ID: <CANCZdfogvSXzHT33JxzvZ%2B0h8BjRetM=-vkPjzhyNJgznPhAnQ@mail.gmail.com> In-Reply-To: <1aafd6a2-828c-06f5-bdac-e4c953a403b5@FreeBSD.org> References: <1aafd6a2-828c-06f5-bdac-e4c953a403b5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfogvSXzHT33JxzvZ%2B0h8BjRetM=-vkPjzhyNJgznPhAnQ>