From: Joonwoo Park <joonwoop@codeaurora.org>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Srivatsa Vaddagiri <vatsa@codeaurora.org>,
Ingo Molnar <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: Fix SCHED_HRTICK bug leading to late preemption of tasks
Date: Mon, 19 Sep 2016 11:08:16 -0700 [thread overview]
Message-ID: <20160919180816.joz2mydmgxmtuvdr@codeaurora.org> (raw)
In-Reply-To: <CANRm+CyC4q=3+yUg48nZG-rAuXQRg6yysnL_=BtjRS=GKbsATg@mail.gmail.com>
On Sun, Sep 18, 2016 at 07:28:32AM +0800, Wanpeng Li wrote:
> 2016-09-17 9:28 GMT+08:00 Joonwoo Park <joonwoop@codeaurora.org>:
> > From: Srivatsa Vaddagiri <vatsa@codeaurora.org>
> >
> > SCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot
> > (just when they would have exceeded their ideal_runtime). It makes use
> > of a per-cpu hrtimer resource and hence alarming that hrtimer should
> > be based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,
> > rather than being based on number of tasks in a particular cfs_rq (as
> > implemented currently). As a result, with current code, its possible for
> > a running task (which is the sole task in its cfs_rq) to be preempted
>
> not be preempted much, right?
I don't think so....
By saying 'to be preempted much after its ideal_runtime has elapsed' I
wanted to describe the current suboptimal behaviour.
Thanks,
Joonwoo
>
> > much after its ideal_runtime has elapsed, resulting in increased latency
> > for tasks in other cfs_rq on same cpu.
> >
> > Fix this by alarming sched hrtimer based on total number of SCHED_FAIR
> > tasks a CPU has across its various cfs_rqs.
> >
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
> > Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
> > ---
> >
> > joonwoop: Do we also need to update or remove if-statement inside
> > hrtick_update()?
> > I guess not because hrtick_update() doesn't want to start hrtick when cfs_rq
> > has large number of nr_running where slice is longer than sched_latency.
> >
> > kernel/sched/fair.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 4088eed..c55c566 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -4458,7 +4458,7 @@ static void hrtick_start_fair(struct rq *rq, struct task_struct *p)
> >
> > WARN_ON(task_rq(p) != rq);
> >
> > - if (cfs_rq->nr_running > 1) {
> > + if (rq->cfs.h_nr_running > 1) {
> > u64 slice = sched_slice(cfs_rq, se);
> > u64 ran = se->sum_exec_runtime - se->prev_sum_exec_runtime;
> > s64 delta = slice - ran;
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > hosted by The Linux Foundation
> >
next prev parent reply other threads:[~2016-09-19 18:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-17 1:28 [PATCH] sched: Fix SCHED_HRTICK bug leading to late preemption of tasks Joonwoo Park
2016-09-17 23:28 ` Wanpeng Li
2016-09-19 18:08 ` Joonwoo Park [this message]
2016-09-19 23:30 ` Wanpeng Li
2016-09-19 8:21 ` Peter Zijlstra
2016-09-19 18:04 ` Joonwoo Park
2016-09-19 18:17 ` Joonwoo Park
2016-09-22 14:01 ` [tip:sched/core] sched/fair: " tip-bot for Srivatsa Vaddagiri
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=20160919180816.joz2mydmgxmtuvdr@codeaurora.org \
--to=joonwoop@codeaurora.org \
--cc=kernellwp@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vatsa@codeaurora.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 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.