From: luca abeni <luca.abeni@unitn.it>
To: Henrik Austad <henrik@austad.us>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Juri Lelli <juri.lelli@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Claudio Scordino <claudio@evidence.eu.com>,
Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
Daniel Bistrot de Oliveira <danielbristot@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFD] sched/deadline: Support single CPU affinity
Date: Thu, 10 Nov 2016 13:38:40 +0100 [thread overview]
Message-ID: <20161110133840.7a6faa55@sweethome> (raw)
In-Reply-To: <20161110122100.GA30974@sisyphus.home.austad.us>
Hi Henrik,
On Thu, 10 Nov 2016 13:21:00 +0100
Henrik Austad <henrik@austad.us> wrote:
> On Thu, Nov 10, 2016 at 09:08:07AM +0100, Peter Zijlstra wrote:
[...]
> > We define the time to fail as:
> >
> > ttf(t) := t_d - t_b; where
> >
> > t_d is t's absolute deadline
> > t_b is t's remaining budget
> >
> > This is the last possible moment we must schedule this task such
> > that it can complete its work and not miss its deadline.
>
> To elaborate a bit on this (this is a modified LLF approach if my
> memory serves):
>
> You have the dynamic time-to-failure (TtF), i.e. as the task
> progresses (scheduled to run), the relative time-to-failure will
> remain constant. This can be used to compare thasks to a running task
> and should minimize the number of calculations required.
>
> Then you have the static Time-of-failure (ToF, which is the absoulte
> time when a task will no longer be able to meet its deadline. This is
> what you use for keeping a sorted list of tasks in the runqueue. As
> this is a fixed point in time, you do not have to dynamically update
> or do crazy calculation when inserting/removing threads from the rq.
Sorry, I am missing something here: if ttf is defined as
ttf_i = d_i - q_i
(where d_i is the deadline of thask i and q_i is its remaining budget),
then it also is the time before which you have to schedule task i if
you do not want to miss the deadline... No? So, I do not understand the
difference with tof.
> > If we then augment the regular EDF rules by, for local tasks,
> > considering the time to fail and let this measure override the
> > regular EDF pick when the time to fail can be overran by the EDF
> > pick.
>
> Then, if you do this - do you need to constrict this to a local CPU?
> I *think* you could do this in a global scheduler if you use ToF/TtF
> for all deadline-tasks, I think you should be able to meet deadlines.
I think the ToF/TtF scheduler will be equivalent to LLF (see previous
emails)... Or am I misunderstanding something? (see above)
And LLF is not optimal on multiple CPUs, so I do not think it will be
able to meet deadlines if you use it as a global scheduler.
>
> I had a rant about this way back [1,2 Sec 11.4], I need to sit down
> and re-read most of it, it has been a few too many years, but the
> idea was to minimize the number of context-switches (which LLF is
> prone to get a lot of) as well as minimize the computational overhead
> by avoiding re-calculating time-of-failre/time-to-failre a lot.
>
> > That is, when:
> >
> > now + left_b > min(ttf)
>
> Why not just use ttf/tof for all deadline-tasks? We have all the
> information available anyway and it would probably make the internal
> logic easier?
I think LLF causes more preemptions and migrations than EDF.
Luca
next prev parent reply other threads:[~2016-11-10 12:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-10 8:08 [RFD] sched/deadline: Support single CPU affinity Peter Zijlstra
2016-11-10 9:06 ` luca abeni
2016-11-10 10:59 ` Peter Zijlstra
2016-11-10 12:27 ` luca abeni
2016-11-10 11:03 ` Tommaso Cucinotta
2016-11-10 14:34 ` luca abeni
2016-11-10 10:01 ` Tommaso Cucinotta
2016-12-13 10:21 ` Peter Zijlstra
2016-12-15 11:30 ` Tommaso Cucinotta
2016-12-15 12:16 ` Peter Zijlstra
2016-11-10 12:21 ` Henrik Austad
2016-11-10 12:38 ` luca abeni [this message]
2016-11-10 12:56 ` Henrik Austad
2016-11-10 14:23 ` luca abeni
2016-11-10 12:56 ` 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=20161110133840.7a6faa55@sweethome \
--to=luca.abeni@unitn.it \
--cc=claudio@evidence.eu.com \
--cc=danielbristot@gmail.com \
--cc=henrik@austad.us \
--cc=juri.lelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tommaso.cucinotta@sssup.it \
/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