From: luca abeni <luca.abeni@unitn.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: 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>,
Henrik Austad <henrik@austad.us>,
linux-kernel@vger.kernel.org
Subject: Re: [RFD] sched/deadline: Support single CPU affinity
Date: Thu, 10 Nov 2016 13:27:05 +0100 [thread overview]
Message-ID: <20161110132705.46340cd4@sweethome> (raw)
In-Reply-To: <20161110105918.GT3142@twins.programming.kicks-ass.net>
Hi Peter,
On Thu, 10 Nov 2016 11:59:18 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
[...]
> > > MIXED CRITICALITY SCHEDULING
> > >
> > > Since we want to provide better guarantees for single CPU affine
> > > tasks than the G-EDF scheduler provides for the single CPU tasks,
> > > we need to somehow alter the scheduling algorithm.
> > >
> > > The trivial layered EDF/G-EDF approach is obviously flawed in
> > > that it will result in many unnecessary deadline misses. The
> > > trivial example is having a single CPU task with a deadline after
> > > a runnable global task. By always running single CPU tasks over
> > > global tasks we can make the global task miss its deadline even
> > > though we could easily have ran both within the alloted time.
>
> > Ok; the layered approach clearly causes some unneeded deadline
> > misses on global tasks... But those tasks risk to miss deadlines
> > anyway (with the corrent scheduler, they are guaranteed to have a
> > limited tardiness, not to respect all of the deadlines). I think
> > this is related to the question about which guarantees are provided
> > to the global tasks.
>
> Right, so I wanted to limit the impact. Basically, given a stronger
> admission test for the GEDF scheduler that would guarantee deadlines,
> I would like the new scheduling function to still guarantee all
> deadlines.
Ok; this is interesting... I do not know if it is possible, but it is
definitly something interesting to look at.
> > > Therefore we must use a more complicated scheme. By adding a
> > > second measure present in the sporadic task model to the
> > > scheduling function we can try and distinguish between the
> > > constraints of handling the two cases in a single scheduler.
> > >
> > > 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
>
> > Ok; I think this is similar to what is called "pseudo-deadline" in
> > some papers.
> > If I understand well, it is equal to the current time + the task
> > "laxity" (or slack time). So, scheduling the task with the smaller
> > ttf is equivalent to the "least laxity first" (LLF) algorithm.
> > Giving precedence to tasks with 0 laxity is a technique that is
> > often used to improve the schedulability on multi-processor
> > systems.
>
> Right, similar to LLF. Initially I was using the term laxity here, but
> Hendrik convinced me that this is called time-to-fail. I'll let him
> explain :-)
Well, if I understand well "time-to-fail" is equal to "laxity + current
time"... So, they are two different quantities but the final scheduling
algorithm is the same (and using ttf simplifies the implementation a
lot :).
> But yes, a pure TTF based scheduler should be equivalent to LLF which
> itself is fairly similar to EDF in that its optimal for UP etc.. (I
> think).
Right
> > I _suspect_ that the migration rules must also be changed (when a
> > task migrates from a runqueue, it currently selects as a target the
> > runqueue having the largest earliest deadline... Maybe it should
> > also consider the presence of rq-local tasks - or the LLF-ordered
> > heap - on the target?)
>
> Quite possible, I didn't think about that.
>
> > Did you find this scheduling strategy on some paper? Otherwise, I
> > think we need to develop some theoretical analysis for it... (which
> > is of course another interesting thing! :)
>
> No, I cooked this up myself. There might of course still be a paper on
> this, but if so, I'm blissfully unaware.
Ok; I'll try to have a look at the theoretical analysis.
Thanks,
Luca
next prev parent reply other threads:[~2016-11-10 12:27 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 [this message]
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
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=20161110132705.46340cd4@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;
as well as URLs for NNTP newsgroup(s).