From: Vincent Guittot <vincent.guittot@linaro.org>
To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, linux-kernel@vger.kernel.org,
parth@linux.ibm.com, tj@kernel.org, lizefan.x@bytedance.com,
hannes@cmpxchg.org, cgroups@vger.kernel.org, corbet@lwn.net,
linux-doc@vger.kernel.org
Cc: qyousef@layalina.io, chris.hyser@oracle.com,
patrick.bellasi@matbug.net, David.Laight@aculab.com,
pjt@google.com, pavel@ucw.cz, qperret@google.com,
tim.c.chen@linux.intel.com, joshdon@google.com, timj@gnu.org,
kprateek.nayak@amd.com, yu.c.chen@intel.com,
youssefesmat@chromium.org, joel@joelfernandes.org,
Vincent Guittot <vincent.guittot@linaro.org>
Subject: [PATCH v12 1/8] sched/fair: fix unfairness at wakeup
Date: Fri, 24 Feb 2023 10:34:47 +0100 [thread overview]
Message-ID: <20230224093454.956298-2-vincent.guittot@linaro.org> (raw)
In-Reply-To: <20230224093454.956298-1-vincent.guittot@linaro.org>
At wake up, the vruntime of a task is updated to not be more older than
a sched_latency period behind the min_vruntime. This prevents long sleeping
task to get unlimited credit at wakeup.
Such waking task should preempt current one to use its CPU bandwidth but
wakeup_gran() can be larger than sched_latency, filter out the
wakeup preemption and as a results steals some CPU bandwidth to
the waking task.
Make sure that a task, which vruntime has been capped, will preempt current
task and use its CPU bandwidth even if wakeup_gran() is in the same range
as sched_latency.
If the waking task failed to preempt current it could to wait up to
sysctl_sched_min_granularity before preempting it during next tick.
Strictly speaking, we should use cfs->min_vruntime instead of
curr->vruntime but it doesn't worth the additional overhead and complexity
as the vruntime of current should be close to min_vruntime if not equal.
Reported-by: Youssef Esmat <youssefesmat@chromium.org>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
kernel/sched/fair.c | 46 ++++++++++++++++++++------------------------
kernel/sched/sched.h | 34 +++++++++++++++++++++++++++++++-
2 files changed, 54 insertions(+), 26 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ff4dbbae3b10..81bef11eb660 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4654,33 +4654,17 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial)
u64 vruntime = cfs_rq->min_vruntime;
u64 sleep_time;
- /*
- * The 'current' period is already promised to the current tasks,
- * however the extra weight of the new task will slow them down a
- * little, place the new task so that it fits in the slot that
- * stays open at the end.
- */
- if (initial && sched_feat(START_DEBIT))
- vruntime += sched_vslice(cfs_rq, se);
-
- /* sleeps up to a single latency don't count. */
- if (!initial) {
- unsigned long thresh;
-
- if (se_is_idle(se))
- thresh = sysctl_sched_min_granularity;
- else
- thresh = sysctl_sched_latency;
-
+ if (!initial)
+ /* sleeps up to a single latency don't count. */
+ vruntime -= get_sleep_latency(se_is_idle(se));
+ else if (sched_feat(START_DEBIT))
/*
- * Halve their sleep time's effect, to allow
- * for a gentler effect of sleepers:
+ * The 'current' period is already promised to the current tasks,
+ * however the extra weight of the new task will slow them down a
+ * little, place the new task so that it fits in the slot that
+ * stays open at the end.
*/
- if (sched_feat(GENTLE_FAIR_SLEEPERS))
- thresh >>= 1;
-
- vruntime -= thresh;
- }
+ vruntime += sched_vslice(cfs_rq, se);
/*
* Pull vruntime of the entity being placed to the base level of
@@ -7721,6 +7705,18 @@ wakeup_preempt_entity(struct sched_entity *curr, struct sched_entity *se)
return -1;
gran = wakeup_gran(se);
+
+ /*
+ * At wake up, the vruntime of a task is capped to not be older than
+ * a sched_latency period compared to min_vruntime. This prevents long
+ * sleeping task to get unlimited credit at wakeup. Such waking up task
+ * has to preempt current in order to not lose its share of CPU
+ * bandwidth but wakeup_gran() can become higher than scheduling period
+ * for low priority task. Make sure that long sleeping task will get a
+ * chance to preempt current.
+ */
+ gran = min_t(s64, gran, get_latency_max());
+
if (vdiff > gran)
return 1;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 3e8df6d31c1e..51ba0af7fb27 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2458,9 +2458,9 @@ extern void check_preempt_curr(struct rq *rq, struct task_struct *p, int flags);
extern const_debug unsigned int sysctl_sched_nr_migrate;
extern const_debug unsigned int sysctl_sched_migration_cost;
-#ifdef CONFIG_SCHED_DEBUG
extern unsigned int sysctl_sched_latency;
extern unsigned int sysctl_sched_min_granularity;
+#ifdef CONFIG_SCHED_DEBUG
extern unsigned int sysctl_sched_idle_min_granularity;
extern unsigned int sysctl_sched_wakeup_granularity;
extern int sysctl_resched_latency_warn_ms;
@@ -2475,6 +2475,38 @@ extern unsigned int sysctl_numa_balancing_scan_size;
extern unsigned int sysctl_numa_balancing_hot_threshold;
#endif
+static inline unsigned long get_sleep_latency(bool idle)
+{
+ unsigned long thresh;
+
+ if (idle)
+ thresh = sysctl_sched_min_granularity;
+ else
+ thresh = sysctl_sched_latency;
+
+ /*
+ * Halve their sleep time's effect, to allow
+ * for a gentler effect of sleepers:
+ */
+ if (sched_feat(GENTLE_FAIR_SLEEPERS))
+ thresh >>= 1;
+
+ return thresh;
+}
+
+static inline unsigned long get_latency_max(void)
+{
+ unsigned long thresh = get_sleep_latency(false);
+
+ /*
+ * If the waking task failed to preempt current it could to wait up to
+ * sysctl_sched_min_granularity before preempting it during next tick.
+ */
+ thresh -= sysctl_sched_min_granularity;
+
+ return thresh;
+}
+
#ifdef CONFIG_SCHED_HRTICK
/*
--
2.34.1
next prev parent reply other threads:[~2023-02-24 9:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 9:34 [PATCH v12 0/8] Add latency priority for CFS class Vincent Guittot
2023-02-24 9:34 ` Vincent Guittot [this message]
2023-02-24 9:34 ` [PATCH v12 2/8] sched: Introduce latency-nice as a per-task attribute Vincent Guittot
2023-02-24 9:34 ` [PATCH v12 3/8] sched/core: Propagate parent task's latency requirements to the child task Vincent Guittot
2023-02-24 9:34 ` [PATCH v12 4/8] sched: Allow sched_{get,set}attr to change latency_nice of the task Vincent Guittot
[not found] ` <20230224093454.956298-1-vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2023-02-24 9:34 ` [PATCH v12 5/8] sched/fair: Take into account latency priority at wakeup Vincent Guittot
2023-03-01 19:28 ` shrikanth hegde
2023-03-02 7:43 ` Vincent Guittot
2023-03-02 11:02 ` Shrikanth Hegde
[not found] ` <d09a4aba-7041-8918-cd33-7d965870ba2b-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2023-03-02 13:05 ` Vincent Guittot
2023-02-24 9:34 ` [PATCH v12 8/8] sched/fair: Add latency list Vincent Guittot
2023-03-01 18:46 ` shrikanth hegde
2023-03-02 7:50 ` Vincent Guittot
2023-03-02 10:59 ` Shrikanth Hegde
[not found] ` <913b0491-cef6-87ac-bf7e-d6d6c8fc380a-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2023-03-02 13:17 ` Vincent Guittot
2023-03-02 15:00 ` Shrikanth Hegde
2023-03-02 18:07 ` Shrikanth Hegde
2023-03-03 16:31 ` Vincent Guittot
2023-03-04 15:11 ` Shrikanth Hegde
2023-03-05 13:03 ` Vincent Guittot
2023-03-06 11:33 ` Shrikanth Hegde
2023-03-06 14:56 ` Vincent Guittot
2023-03-06 19:04 ` Shrikanth Hegde
[not found] ` <ed4a5323-44e8-590e-1050-4b7b948c5688-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2023-03-07 10:19 ` Vincent Guittot
2023-03-07 10:50 ` Shrikanth Hegde
[not found] ` <69e18715-f868-132b-8898-0787a60e6840-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2023-03-08 8:00 ` Vincent Guittot
[not found] ` <CAKfTPtDLptU9j9iCRtOokYzRE0SMqXZHBH0xPjqhaB=NPOes4w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-03-08 15:22 ` Shrikanth Hegde
[not found] ` <20230224093454.956298-9-vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2023-03-01 19:31 ` shrikanth hegde
2023-02-24 9:34 ` [PATCH v12 6/8] sched/fair: Add sched group latency support Vincent Guittot
[not found] ` <20230224093454.956298-7-vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2023-02-24 19:29 ` Michal Koutný
2023-02-27 13:44 ` Vincent Guittot
2023-02-27 14:42 ` Michal Koutný
2023-02-28 9:09 ` Vincent Guittot
2023-02-24 9:34 ` [PATCH v12 7/8] sched/core: Support latency priority with sched core Vincent Guittot
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=20230224093454.956298-2-vincent.guittot@linaro.org \
--to=vincent.guittot@linaro.org \
--cc=David.Laight@aculab.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=chris.hyser@oracle.com \
--cc=corbet@lwn.net \
--cc=dietmar.eggemann@arm.com \
--cc=hannes@cmpxchg.org \
--cc=joel@joelfernandes.org \
--cc=joshdon@google.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=parth@linux.ibm.com \
--cc=patrick.bellasi@matbug.net \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=qperret@google.com \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.com \
--cc=timj@gnu.org \
--cc=tj@kernel.org \
--cc=vschneid@redhat.com \
--cc=youssefesmat@chromium.org \
--cc=yu.c.chen@intel.com \
/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