From: Rik van Riel <riel@surriel.com>
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 <riel@surriel.com>
Subject: [PATCH 08/15] sched,fair: simplify timeslice length code
Date: Wed, 21 Aug 2019 22:17:33 -0400 [thread overview]
Message-ID: <20190822021740.15554-9-riel@surriel.com> (raw)
In-Reply-To: <20190822021740.15554-1-riel@surriel.com>
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 <riel@surriel.com>
---
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 8f8c85c6da9b..74ee22c59d13 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
next prev parent reply other threads:[~2019-08-22 2:18 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 2:17 [PATCH RFC v4 0/15] sched,fair: flatten CPU controller runqueues Rik van Riel
2019-08-22 2:17 ` [PATCH 01/15] sched: introduce task_se_h_load helper Rik van Riel
2019-08-23 18:13 ` Dietmar Eggemann
2019-08-24 0:05 ` Rik van Riel
2019-08-22 2:17 ` [PATCH 02/15] sched: change /proc/sched_debug fields Rik van Riel
2019-08-22 2:17 ` [PATCH 03/15] sched,fair: redefine runnable_load_avg as the sum of task_h_load Rik van Riel
2019-08-28 13:50 ` Vincent Guittot
2019-08-28 14:47 ` Rik van Riel
2019-08-28 15:02 ` Vincent Guittot
2019-08-22 2:17 ` [PATCH 04/15] sched,fair: move runnable_load_avg to cfs_rq Rik van Riel
2019-08-22 2:17 ` [PATCH 05/15] sched,fair: remove cfs_rqs from leaf_cfs_rq_list bottom up Rik van Riel
2019-08-28 14:09 ` Vincent Guittot
2019-08-22 2:17 ` [PATCH 06/15] sched,cfs: use explicit cfs_rq of parent se helper Rik van Riel
2019-08-28 13:53 ` Vincent Guittot
2019-08-28 15:28 ` Rik van Riel
2019-08-28 16:34 ` Vincent Guittot
2019-08-22 2:17 ` [PATCH 07/15] sched,cfs: fix zero length timeslice calculation Rik van Riel
2019-08-28 16:59 ` Vincent Guittot
2019-08-22 2:17 ` Rik van Riel [this message]
2019-08-28 17:32 ` [PATCH 08/15] sched,fair: simplify timeslice length code Vincent Guittot
2019-08-28 23:18 ` Rik van Riel
2019-08-29 14:02 ` Vincent Guittot
2019-08-29 16:00 ` Rik van Riel
2019-08-30 6:41 ` Vincent Guittot
2019-08-30 15:01 ` Rik van Riel
2019-09-02 7:51 ` Vincent Guittot
2019-09-02 17:47 ` Rik van Riel
2019-08-22 2:17 ` [PATCH 09/15] sched,fair: refactor enqueue/dequeue_entity Rik van Riel
2019-09-03 15:38 ` Vincent Guittot
2019-09-03 20:27 ` Rik van Riel
2019-09-04 6:44 ` Vincent Guittot
2019-08-22 2:17 ` [PATCH 10/15] sched,fair: add helper functions for flattened runqueue Rik van Riel
2019-08-22 2:17 ` [PATCH 11/15] sched,fair: flatten hierarchical runqueues Rik van Riel
2019-08-23 18:14 ` Dietmar Eggemann
2019-08-24 1:16 ` Rik van Riel
2019-08-22 2:17 ` [PATCH 12/15] sched,fair: flatten update_curr functionality Rik van Riel
2019-08-27 10:37 ` Dietmar Eggemann
2019-08-22 2:17 ` [PATCH 13/15] sched,fair: propagate sum_exec_runtime up the hierarchy Rik van Riel
2019-08-28 7:51 ` Dietmar Eggemann
2019-08-28 13:14 ` Rik van Riel
2019-08-29 17:20 ` Dietmar Eggemann
2019-08-29 18:06 ` Rik van Riel
2019-08-22 2:17 ` [PATCH 14/15] sched,fair: ramp up task_se_h_weight quickly Rik van Riel
2019-08-22 2:17 ` [PATCH 15/15] sched,fair: scale vdiff in wakeup_preempt_entity Rik van Riel
2019-09-02 10:53 ` [PATCH RFC v4 0/15] sched,fair: flatten CPU controller runqueues Dietmar Eggemann
2019-09-03 1:44 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190822021740.15554-9-riel@surriel.com \
--to=riel@surriel.com \
--cc=dietmar.eggemann@arm.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.