Date:	Tue, 14 Jul 2009 21:07:15 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Noah Watkins <jayhawk@....ucsc.edu>,
	Douglas Niehaus <niehaus@...c.ku.edu>,
	Henrik Austad <henrik@...tad.us>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Bill Huey <billh@...ppy.monkey.org>,
	Linux RT <linux-rt-users@...r.kernel.org>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	"James H. Anderson" <anderson@...unc.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ted Baker <baker@...fsu.edu>,
	Dhaval Giani <dhaval.giani@...il.com>,
	KUSP Google Group <kusp@...glegroups.com>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Giuseppe Lipari <lipari@...is.sssup.it>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel

On Tue, 2009-07-14 at 11:15 +0200, Peter Zijlstra wrote: 
> > Regarding the notion of charging proxy execution to the budget of
> > the client task, I have grave concerns. It is already hard enough
> > to estimate the amount of budget that a real-time task requires,
> > without this additional complication. 
> 
> I hope the above illustrates the use of this, furthermore I think Dario
> and team did some actual analysis on it wrt deadline schedulers. Dario
> could you expand?
> 
Sure, I can try, again! :-)

I think what I said trying to answer Chris is of same help here as well,
and that it already clarified things at least a little bit. Does it?

Anyway, I think we are looking at the problem from slightly different
points standpoints.
I definitely agree with Prof. Baker with the fact that estimating
execution times is very difficult, and I think this extends to the
estimation of durations of critical sections too.

Moreover, there are scenarios where you don't really need strong
knowledge of these time intervals because, e.g., you are mainly
interested in:
 - providing an applications/components with some kind of quality of 
   service --i.e., not hard real-time-- guarantees;
 - isolate the applications/components among themselves.
This is, I think, quite typical for soft real-time workloads that could
run on Linux, better if preempt-rt, without many problems.

With this in mind, what we think is interesting of BWI-like approaches
is, indeed, that they do require virtually no knowledge about tasks'
behaviour, at least to provide timing isolation... No tasks' wcet, no
tasks' accessed mutexes, no tasks' blocking times: just a budget and a
period of a server/group each application is enclosed within.
This is of some relevance, we think, not only in the real-time world,
but also when robustness, availability and dependability starts being
considered.

I think I already said how the thing basically works, and I don't want
to bother you all by explaining it again, unless you ask me for some
clarification... All I can add is that going this way is, actually,
moving toward trying to _remove_ the need of having exact prediction of
task execution and blocking.

Finally, but I already said this as well, if you need hard behaviour and
you have the data about tasks' wcet and blocking times, the paper I
pointed to (the last mail, with working links! :-D) contain all it is
needed to compute the group's budget properly taking into account
interferences... It is, brutally simplifying, something like using as
budget for task A's group the sum of A's wcet plus all the blocking
times of tasks that blocks on it.

And Peter is right, such analysis is done for EDF on UP configurations.
Finally, I unfortunately am not able to provide any clue on how this
applies to fair schedulers (e.g., SFQ/CFS), but don't think it's
impossible... :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@...ga.net /
dario.faggioli@...ber.org

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists