Date:	Fri, 17 Jul 2009 01:07:45 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Ted Baker <baker@...fsu.edu>
Cc:	Chris Friesen <cfriesen@...tel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Noah Watkins <jayhawk@....ucsc.edu>,
	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 Thu, 2009-07-16 at 18:34 -0400, Ted Baker wrote:
> > In this scenario, we're going to disrupt B's scheduling pattern by
> > forcing it to borrow from its future cpu allocation in order to free up
> > the lock.  It will then be forced to block for a while to make up for
> > the over-use of it's cpu budget.
> 
> I guess by "disrupting" B's scheduling pattern, you mean only in
> the sense of delayed budget enforcement.  That is, finishing the
> critical sections is something that B would do next in any case,
> and something that B would need to consume CPU time to do in any
> case.  It is B doing its own normal work, but just getting
> a chance to complete that work sooner than it might otherwise.
> 
> In this situation, you do want to allow B's budget to go negative
> (borrowing against B's future CPU budget to do B's work) rather
> than charging the task A who loaned B priority, since otherwise B
> ends up getting a still bigger windfall (charging B's work to A's
> budget).
> 
When bandwidth and budget are in place, allowing a task to cross these
boundaries if executing inside a critical section is another approach I
always have liked... Provided you have a mean to make it pay back for
its borrowed bandwidth, as you are properly saying.

However, I also think this raises an issue: what if something weird
happen inside the critical section, such that the task overcame its
declared/estimated duration? If no enforcing is in place, aren't we, at
least temporary, breaking the isolation?
And I think bandwidth isolation between a possibly "failing" task and
the rest of the system is exactly what we are trying to achieve when we
use bandwidth reservation mechanisms?

Thus, in scenarios where component isolation is what we care most, and
especially if good estimations of execution, critical section duration
and blocking times are hardly possible, proxy execution/bandwidth
inheritance approaches ensures the following:
1. the task executing the critical section gets some "bonus bandwidth"
   to speedup the completion of that code, but not in an uncontrolled
   manner: i.e., it can use _only_ the bandwidths of tasks blocked on
   that cs;
2. whatever goes on inside a task, including critical sections, it
   _only_ will affect the capability of making their deadline of:
   - the task executing the cs;
   - the tasks interacting with him, i.e., accessing the same cs.
Any other component/task in the system will be completely unaware of
anything!

Obviously, this comes at the price of overhead, tricky implementation,
etc. ... I don't know if it is always worth, probably it is not, but I
think it is yet something remarkable! :-)

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