Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7348462ybi; Mon, 22 Jul 2019 11:27:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqzeEPKGzi/Y41afuDAoKF/2yZYILtxxMc3lb2oGOopdneSWdrBxzJE68YtxCzHPuvKOAYnR X-Received: by 2002:aa7:90d4:: with SMTP id k20mr1510007pfk.78.1563820049138; Mon, 22 Jul 2019 11:27:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563820049; cv=none; d=google.com; s=arc-20160816; b=YHI4mwf7qKTzEmeqrU4dGsysVTzp5Haucf2UjHWxUgPewZGIJcjS1cSOYiRSi5VhNy lY2BXtEmp9o0Mt25fc9EMquV9Ep1S7BUoyl7HFsqOsFo3dIWVWC4hwT+9qahc22SJg0+ J7cg4h4JT5mgyM6aTCNqvFGwvxBAUKeYIM6sczLpdsVOKbSqoiV6SdUabHRiOKiHKH0n OmwHbYGeGY381oFRdROrv9ncpI706FT0Qr3JyyUZqG+2I1F/J+ClVqwwe9KHP48LM1yF EpmSAvBN/yAJ5GZLDUHb2XMonojcGBE4SW1YT5AnYosIWtKSjZoipe7KbEpzyfh+oP3r HEug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=sgwiaTLGqChfax6ZXhVWKuVhBSQeWwvLDTk1V0/hsCs=; b=ksvq0lr7ej6ba4yihSH5bJeR9m9sRGrOnWQqqUJl3AGwvNmbzFzfWrk9GRXzzOJB5W ooCGrXv6LIEsuOuUn0U2FuunNaXvJu+pDba4bSbif0ofQTItON84TOARhZTkdoWAmyc8 tdiHRPFfcTL5b7y+PFQaIMy9QnFJgCUs8Lv0Ki+dkSFHyOs+53tzNi7CQgl6BU7bu48g HOc4sDHL8QGZK6Qj5RZ7yZfroHzjTl510h1CY9VXWnM2s4weuRLdI054ShMmDqGsnbEW 8AtlF70FImYqi1cgrrpbkdFQF8SL6XxckOAd17pElEyzwzAYWf3tWWR1jeyDmD3a7CA9 11Lw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bg3si8072240plb.83.2019.07.22.11.27.13; Mon, 22 Jul 2019 11:27:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728843AbfGVRfG (ORCPT + 99 others); Mon, 22 Jul 2019 13:35:06 -0400 Received: from shelob.surriel.com ([96.67.55.147]:37758 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727796AbfGVReX (ORCPT ); Mon, 22 Jul 2019 13:34:23 -0400 Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpcC8-0003HL-9s; Mon, 22 Jul 2019 13:33:52 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: kernel-team@fb.com, pjt@google.com, dietmar.eggemann@arm.com, peterz@infradead.org, mingo@redhat.com, morten.rasmussen@arm.com, tglx@linutronix.de, mgorman@techsingularity.net, vincent.guittot@linaro.org, Rik van Riel Subject: [PATCH 08/14] sched,fair: simplify timeslice length code Date: Mon, 22 Jul 2019 13:33:42 -0400 Message-Id: <20190722173348.9241-9-riel@surriel.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190722173348.9241-1-riel@surriel.com> References: <20190722173348.9241-1-riel@surriel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The idea behind __sched_period makes sense, but the results do not always. When a CPU has one high priority task and a large number of low priority tasks, __sched_period will return a value larger than sysctl_sched_latency, and the one high priority task may end up getting a timeslice all for itself that is also much larger than sysctl_sched_latency. The low priority tasks will have their time slices rounded up to sysctl_sched_min_granularity, resulting in an even larger scheduling latency than targeted by __sched_period. Simplify the code by simply ripping out __sched_period and always taking fractions of sysctl_sched_latency. If a high priority task ends up getting a "too small" time slice compared to low priority tasks, the vruntime scaling ensures that it will simply get scheduled more frequently than low priority tasks. Signed-off-by: Rik van Riel --- kernel/sched/fair.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 9ff69b927a3c..b4fc328032e6 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -691,22 +691,6 @@ static inline u64 calc_delta_fair(u64 delta, struct sched_entity *se) return delta; } -/* - * The idea is to set a period in which each task runs once. - * - * When there are too many tasks (sched_nr_latency) we have to stretch - * this period because otherwise the slices get too small. - * - * p = (nr <= nl) ? l : l*nr/nl - */ -static u64 __sched_period(unsigned long nr_running) -{ - if (unlikely(nr_running > sched_nr_latency)) - return nr_running * sysctl_sched_min_granularity; - else - return sysctl_sched_latency; -} - /* * We calculate the wall-time slice from the period by taking a part * proportional to the weight. @@ -715,7 +699,7 @@ static u64 __sched_period(unsigned long nr_running) */ static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se) { - u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq); + u64 slice = sysctl_sched_latency; for_each_sched_entity(se) { struct load_weight *load; -- 2.20.1