mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Xuewen Yan <xuewen.yan@unisoc.com>
To: <peterz@infradead.org>, <mingo@redhat.com>,
	<juri.lelli@redhat.com>, <vincent.guittot@linaro.org>
Cc: <dietmar.eggemann@arm.com>, <rostedt@goodmis.org>,
	<bsegall@google.com>, <mgorman@suse.de>, <bristot@redhat.com>,
	<vschneid@redhat.com>, <wuyun.abel@bytedance.com>,
	<ke.wang@unisoc.com>, <xuewen.yan94@gmail.com>,
	<linux-kernel@vger.kernel.org>
Subject: [PATCH] sched/eevdf: Prevent vlag from exceeding the limit value
Date: Tue, 30 Jan 2024 16:06:43 +0800	[thread overview]
Message-ID: <20240130080643.1828-1-xuewen.yan@unisoc.com> (raw)

There are some scenarios here that will cause vlag to
exceed eevdf's limit.

1. In set_next_entity, it will stash a copy of deadline
at the point of pick in vlag, and if the task fork child,
the child's vlag would inherit parent's vlag, as a result,
the child's vlag is equal to the deadline. And then,
when place_entity, because the se's vlag is wrong, it would
cause vruntime and deadline update error.

2. When reweight_entity, the vlag would be recalculated,
because the new weights are uncertain, and it may cause
the vlag to exceed eevdf's limit.

In order to ensure that vlag does not exceed the limit,
separate the calculation of limit from the update_entity_lag
and create a new func limit_entity_lag. When the vlag is
updated, use this func to prevent vlag from exceeding the limit.

And add check whether the se is forked in place_entity, and calc
the curr's vlag to update the se's vlag.

Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
---
 kernel/sched/fair.c | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 533547e3c90a..3fc99b4b8b41 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -696,15 +696,22 @@ u64 avg_vruntime(struct cfs_rq *cfs_rq)
  *
  * XXX could add max_slice to the augmented data to track this.
  */
+static s64 limit_entity_lag(struct sched_entity *se, s64 lag)
+{
+	s64 limit;
+
+	limit = calc_delta_fair(max_t(u64, 2*se->slice, TICK_NSEC), se);
+	return clamp(lag, -limit, limit);
+}
+
 static void update_entity_lag(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
-	s64 lag, limit;
+	s64 lag;
 
 	SCHED_WARN_ON(!se->on_rq);
 	lag = avg_vruntime(cfs_rq) - se->vruntime;
 
-	limit = calc_delta_fair(max_t(u64, 2*se->slice, TICK_NSEC), se);
-	se->vlag = clamp(lag, -limit, limit);
+	se->vlag = limit_entity_lag(se, lag);
 }
 
 /*
@@ -3757,6 +3764,7 @@ static void reweight_eevdf(struct cfs_rq *cfs_rq, struct sched_entity *se,
 	if (avruntime != se->vruntime) {
 		vlag = (s64)(avruntime - se->vruntime);
 		vlag = div_s64(vlag * old_weight, weight);
+		vlag = limit_entity_lag(se, vlag);
 		se->vruntime = avruntime - vlag;
 	}
 
@@ -3804,6 +3812,9 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
 
 	update_load_set(&se->load, weight);
 
+	if (!se->on_rq)
+		se-vlag = limit_entity_lag(se, se->vlag);
+
 #ifdef CONFIG_SMP
 	do {
 		u32 divider = get_pelt_divider(&se->avg);
@@ -5177,6 +5188,16 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
 
 		lag = se->vlag;
 
+		/* When fork, the child would inherit parent's vlag,
+		 * but parent's vlag may be euqual to it's deadline.
+		 */
+		if (flag & ENQUEUE_INITIAL) {
+			if (curr)
+				lag = vruntime - curr->vruntime;
+
+			lag = limit_entity_lag(se, lag);
+			se->vlag = lag;
+		}
 		/*
 		 * If we want to place a task and preserve lag, we have to
 		 * consider the effect of the new entity on the weighted
@@ -5237,6 +5258,7 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
 		if (WARN_ON_ONCE(!load))
 			load = 1;
 		lag = div_s64(lag, load);
+		lag = limit_entity_lag(se, lag);
 	}
 
 	se->vruntime = vruntime - lag;
-- 
2.25.1


             reply	other threads:[~2024-01-30  8:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30  8:06 Xuewen Yan [this message]
2024-02-05  6:36 ` Xuewen Yan
2024-04-08 12:06 ` Peter Zijlstra
2024-04-18  2:50   ` Xuewen Yan

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=20240130080643.1828-1-xuewen.yan@unisoc.com \
    --to=xuewen.yan@unisoc.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=ke.wang@unisoc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=wuyun.abel@bytedance.com \
    --cc=xuewen.yan94@gmail.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

all inboxes | Powered by JetHome®