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 15/15] sched,fair: scale vdiff in wakeup_preempt_entity
Date: Wed, 21 Aug 2019 22:17:40 -0400 [thread overview]
Message-ID: <20190822021740.15554-16-riel@surriel.com> (raw)
In-Reply-To: <20190822021740.15554-1-riel@surriel.com>
When a task wakes back up after having gone to sleep, place_entity
will limit the vruntime difference between min_vruntime and the
woken up task to half of sysctl_sched_latency.
The code in wakeup_preempt_entity calculates how much vruntime a
time slice for the woken up task represents, in wakeup_gran.
It then assumes that all the vruntime used since the task went to
sleep was used by the currently running task (which has its vruntime
scaled by calc_delta_fair, as well).
However, that assumption is not necessarily true, and the vruntime
may have advanced at different rates, pushed ahead by different tasks
on the CPU. This becomes more visible when the CPU controller is enabled.
This leads to the symptom that a high priority woken up task is likely to
preempt whatever is running, even if the currently running task is of equal
or higher priority than the woken up task!
Scaling the vdiff down if the currently running task is also high priority
solves that symptom.
This is not the correct thing to do if all of the vruntime was accumulated
by the current task, or other tasks at similar priority, and already scaled
by the same priority, but I do not have any better ideas on how to tackle
the "task X got preempted by task Y of the same priority" issue that system
administrators try to resolve by setting the sched_wakeup_granularity
sysctl variable to a larger value than half of sysctl_sched_latency...
Signed-off-by: Rik van Riel <riel@surriel.com>
---
kernel/sched/fair.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3df5d60b245f..ef7629bdf41d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6774,6 +6774,7 @@ wakeup_preempt_entity(struct sched_entity *curr, struct sched_entity *se)
if (vdiff <= 0)
return -1;
+ vdiff = min((u64)vdiff, calc_delta_fair(vdiff, curr));
gran = wakeup_gran(se);
if (vdiff > gran)
return 1;
--
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 ` [PATCH 08/15] sched,fair: simplify timeslice length code Rik van Riel
2019-08-28 17:32 ` 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 ` Rik van Riel [this message]
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-16-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox