From: Chunxin Zang <spring.cxz@gmail.com>
To: mingo@redhat.com, peterz@infradead.org, 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, linux-kernel@vger.kernel.org,
yu.c.chen@intel.com, yangchen11@lixiang.com,
zhouchunhua@lixiang.com, zangchunxin@lixiang.com,
Chunxin Zang <spring.cxz@gmail.com>
Subject: [PATCH] sched/fair: Reschedule the cfs_rq when current is ineligible
Date: Fri, 24 May 2024 21:40:11 +0800 [thread overview]
Message-ID: <20240524134011.270861-1-spring.cxz@gmail.com> (raw)
I found that some tasks have been running for a long enough time and
have become illegal, but they are still not releasing the CPU. This
will increase the scheduling delay of other processes. Therefore, I
tried checking the current process in wakeup_preempt and entity_tick,
and if it is illegal, reschedule that cfs queue.
The modification can reduce the scheduling delay by about 30% when
RUN_TO_PARITY is enabled.
So far, it has been running well in my test environment, and I have
pasted some test results below.
I isolated four cores for testing. I ran Hackbench in the background
and observed the test results of cyclictest.
hackbench -g 4 -l 100000000 &
cyclictest --mlockall -D 5m -q
EEVDF PATCH EEVDF-NO_PARITY PATCH-NO_PARITY
# Min Latencies: 00006 00006 00006 00006
LNICE(-19) # Avg Latencies: 00191 00122 00089 00066
# Max Latencies: 15442 07648 14133 07713
# Min Latencies: 00006 00010 00006 00006
LNICE(0) # Avg Latencies: 00466 00277 00289 00257
# Max Latencies: 38917 32391 32665 17710
# Min Latencies: 00019 00053 00010 00013
LNICE(19) # Avg Latencies: 37151 31045 18293 23035
# Max Latencies: 2688299 7031295 426196 425708
I'm actually a bit hesitant about placing this modification under the
NO_PARITY feature. This is because the modification conflicts with the
semantics of RUN_TO_PARITY. So, I captured and compared the number of
resched occurrences in wakeup_preempt to see if it introduced any
additional overhead.
Similarly, hackbench is used to stress the utilization of four cores to
100%, and the method for capturing the number of PREEMPT occurrences is
referenced from [1].
schedstats EEVDF PATCH EEVDF-NO_PARITY PATCH-NO_PARITY CFS(6.5)
.stats.check_preempt_count 5053054 5057286 5003806 5018589 5031908
.stats.patch_cause_preempt_count ------- 858044 ------- 765726 -------
.stats.need_preempt_count 570520 858684 3380513 3426977 1140821
From the above test results, there is a slight increase in the number of
resched occurrences in wakeup_preempt. However, the results vary with each
test, and sometimes the difference is not that significant. But overall,
the count of reschedules remains lower than that of CFS and is much less
than that of NO_PARITY.
[1]: https://lore.kernel.org/all/20230816134059.GC982867@hirez.programming.kicks-ass.net/T/#m52057282ceb6203318be1ce9f835363de3bef5cb
Signed-off-by: Chunxin Zang <zangchunxin@lixiang.com>
Reviewed-by: Chen Yang <yangchen11@lixiang.com>
---
kernel/sched/fair.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 03be0d1330a6..a0005d240db5 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5523,6 +5523,9 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued)
hrtimer_active(&rq_of(cfs_rq)->hrtick_timer))
return;
#endif
+
+ if (!entity_eligible(cfs_rq, curr))
+ resched_curr(rq_of(cfs_rq));
}
@@ -8325,6 +8328,9 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int
if (unlikely(p->policy != SCHED_NORMAL) || !sched_feat(WAKEUP_PREEMPTION))
return;
+ if (!entity_eligible(cfs_rq, se))
+ goto preempt;
+
find_matching_se(&se, &pse);
WARN_ON_ONCE(!pse);
--
2.34.1
next reply other threads:[~2024-05-24 13:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 13:40 Chunxin Zang [this message]
2024-05-24 15:30 ` [PATCH] sched/fair: Reschedule the cfs_rq when current is ineligible Chen Yu
2024-05-28 2:42 ` Chunxin Zang
2024-05-28 5:02 ` K Prateek Nayak
2024-05-28 7:18 ` Chunxin Zang
2024-05-28 7:47 ` K Prateek Nayak
2024-06-05 17:19 ` Chen Yu
2024-06-06 1:46 ` Chunxin Zang
2024-06-07 2:38 ` Chen Yu
2024-06-11 13:10 ` Chunxin Zang
2024-06-13 11:45 ` Chen Yu
2024-05-28 6:41 ` Chunxin Zang
2024-05-25 6:41 ` Mike Galbraith
2024-05-25 11:57 ` Chen Yu
2024-05-25 17:22 ` Mike Galbraith
2024-05-27 8:05 ` Peter Zijlstra
2024-05-27 9:53 ` Mike Galbraith
2024-05-25 11:48 ` Honglei Wang
[not found] ` <6AF97701-B8F4-46C6-851E-A8BACE97E8C0@gmail.com>
2024-06-03 2:55 ` Honglei Wang
2024-06-06 12:39 ` Chunxin Zang
2024-06-11 11:39 ` Honglei Wang
2024-05-29 6:06 ` kernel test robot
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=20240524134011.270861-1-spring.cxz@gmail.com \
--to=spring.cxz@gmail.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.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=yangchen11@lixiang.com \
--cc=yu.c.chen@intel.com \
--cc=zangchunxin@lixiang.com \
--cc=zhouchunhua@lixiang.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 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.