From owner-freebsd-hackers@freebsd.org Wed Mar 29 21:18:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE549D249DE for ; Wed, 29 Mar 2017 21:18:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB76C16D for ; Wed, 29 Mar 2017 21:18:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id f84so7419100ioj.0 for ; Wed, 29 Mar 2017 14:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pqw/Cp3T0QKPN+fkxAEr5wnv6k46nQx4JcivkkTXrcA=; b=kvOOVgILFs3z0hhKCFYD1mD8Eai3iviXxAMHW8BNJKYNc6B5WM4c0Gw58Iaws1o710 XcbjX5S6wTFFkQWj3ffnmDdn4UdGBDCK1kuJUWL2hxIUTkQtJbYn0Cq3JnICo8O/z2us iINWfG0m8aHyNA2sYEq8A7WPav9YAotF4FPsRal6w2UZkzStmdzXO9zUN9bmWxzmhLC2 N3K0+Ql7tpBJ0XkSLrzlu9a5RK3d9Th3qGp2YMe5qWewfnu6Pud8Vc29miA3em0YiE5l 3efTPB7bVBr+twQxDWxCrXrEz56T8KT9mBqxomUJ6cuM5DeZszHSEDx7Py5cztUPsm3k NWlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pqw/Cp3T0QKPN+fkxAEr5wnv6k46nQx4JcivkkTXrcA=; b=Df9oUnBiUgeAkGIsD9RzYjulA1x1WbPi6L7YAMkFSfxg/SijifXVBvyRzUGnUC9S4t 4/zpqwezlLTprUHpDtBu8UkVgD1YTAQjSo92sSLZiy4SovkoSPzA62zV7FGrfz063cdP 3Yrz17eCVG8J28bBTQkBVVGz4zqclyoZk4rbOjQNmfYijefjuiIn9xBtGtvkRov4JHG8 RpGmo5mRy5bvRdBQ5jQJPSKGU7AP2pfd/zeuyaZmpPFdJ4rr5ZKGLWAoDxLVXcOrLJ2M JAIu2Rn8qcooB8m6c/ce4r0nHIESExDD2HL7UlEF69hQnQxXGsBySjQYSI8Qki9aUhkD MF3g== X-Gm-Message-State: AFeK/H2EoBD398mCR38qs5mxQiqXgSEWQ+hcZ9xskkpEWEwrn7cVzmYTBmkR4QHNyCuIRyuMZ46jLAxKv9rT3A== X-Received: by 10.107.198.193 with SMTP id w184mr3069265iof.19.1490822333804; Wed, 29 Mar 2017 14:18:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Wed, 29 Mar 2017 14:18:53 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:a045:c633:4156:d07c] In-Reply-To: <1aafd6a2-828c-06f5-bdac-e4c953a403b5@FreeBSD.org> References: <1aafd6a2-828c-06f5-bdac-e4c953a403b5@FreeBSD.org> From: Warner Losh Date: Wed, 29 Mar 2017 15:18:53 -0600 X-Google-Sender-Auth: mnnwpx_dfnUCxqMQ5qDtAA5wC_0 Message-ID: Subject: Re: One Priority Per Run Queue To: Eric van Gyzen Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:18:55 -0000 On Wed, Mar 29, 2017 at 2:00 PM, Eric van Gyzen 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"