From: "weiqi (C)" <weiqi4@huawei.com>
To: <linux-kernel@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>
Subject: [RFC] sched/fair: Align vruntime to last_se when curr_se's timeslice run out
Date: Wed, 5 Dec 2018 20:41:39 +0800 [thread overview]
Message-ID: <f4f56ab5-8f9e-9ee4-4db8-370bc4aa2556@huawei.com> (raw)
Hello,
I measuring the cfs scheduling delay, and found that
when a cfs_rq contains multiple tasks, it does not guarantee
every se of this cfs_rq can get a changce to run within
one sched_latency period. Assume that there are three se
A, B, and C in cfs_rq, and the default sched_latency=24ms.
In ideal state, A, B, and C take turns to get 8ms, The timing is:
A(8ms) -> B(8ms) -> C(8ms) -> A(8ms) -> B(8ms) -> C(8ms) ....
So, the delay for each task is approximately 16ms.
However, check_preempt_tick() is the clock interrupt granularity,
and the clock interrupt may also have an indeterminate fine delay,
so the time slice actually expires relative
to the ideal expiration time delay uncertain time.
This may result in a timing of :
A -> B -> C -> B -> C -> A
which increases the scheduling delay of A to 32ms.
The more extreme scenario is wakeup sleepers. If a sleeper task
wakes up to a cpu, its vruntime will be sched_latency/2 less
than cfs_rq->min_vruntime /* place_entity() function do this */
In the scene of the above A, B, C cycle time slice,
a sleeper thread D woken up
D->vruntime = cfs_rq->min_vruntime - sched_latency/2
then the timing of the pick_task may be:
A(8ms)->B(8ms)->C(8ms)->D(6ms)->D(6ms)->D(6ms,then dequeue)->C(8ms)->
B(8ms)->A
causing A's scheduling delay to reach 50ms
so, I make changes to check_preempt_tick():
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ee271bb..1f61b9c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4020,7 +4020,23 @@ static void clear_buddies(struct cfs_rq *cfs_rq,
struct sched_entity *se)
ideal_runtime = sched_slice(cfs_rq, curr);
delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime;
if (delta_exec > ideal_runtime) {
+ struct rb_node *next = NULL;
+ struct rb_node *right_most = NULL;
+ struct sched_entity *last;
resched_curr(rq_of(cfs_rq));
+
+ /* always set to max vruntime */
+ if (cfs_rq->nr_running > 1) {
+ next = &curr->run_node;
+ do {
+ right_most = next;
+ next = rb_next(next);
+ } while (next);
+
+ last = rb_entry(right_most,
+ struct sched_entity, run_node);
+ curr->vruntime = last->vruntime + 1; // maybe
+1 is not needed
+ }
+
/*
* The current task ran long enough, ensure it doesn't get
* re-elected due to buddy favours.
In this way, time sliced task in one sched_latency period will not get
runtime again,
And for wake sleeper, it can meet the needs of wake-up preemption, and
this will not let it
take too much time in a scheduling period.
I wrote a small press program, bind it to 12 cpus, this program wake up
36 sub-processes
every second and each sub-process work 120ms, looping all the time..
I‘ve tested on linux-stable 4.20-rc1 kernel, the maximum delay of press
program is about 80ms.
After applying the above modifications, the maximum delay is stable at 27ms.
next reply other threads:[~2018-12-05 12:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 12:41 weiqi (C) [this message]
2018-12-06 9:36 ` Peter Zijlstra
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=f4f56ab5-8f9e-9ee4-4db8-370bc4aa2556@huawei.com \
--to=weiqi4@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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
all inboxes | Powered by JetHome®