Re: [RFC Patch 0/3] Putting the "Simple" back in sedf.

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4402 bytes --]

On ven, 2014-03-14 at 16:13 -0400, Nate Studer wrote:
> On 3/14/2014 3:22 PM, George Dunlap wrote:
> > 
> > Hey Nate,
> > 
> > Thanks for these patches -- what you describe at a high level, making 
> > sedf a suitable rts for embedded applications, sounds like a great idea.
> > 
It does indeed... And thanks a ton for stepping up! As said many times,
this is something I always wanted to do/make happen, but could never
find enough time for actually doing.

Having someone like you and Josh and you on board is absolutely great,
thanks again! :-)

> > I think what might be helpful in evaluating whether these patches are a 
> > good idea at the high level is a bit of a description of where you see 
> > this going long-term.  Can you sketch out, at a high level, what you 
> > envision the sedf scheduler becoming?  What kinds of parameters and 
> > features *will* it have?
> 
> In the long term, a more extensible version of Dario's favorite scheduler, CBS
> (Constant Bandwidth Server):  a selectable budgeting algorithm that sets vcpu
> deadlines with the sedf scheduler on the backend scheduling the vcpu with the
> earliest deadline.  Preferably it would support other budgeting algorithms as
> well such as Total Bandwidth Server, etc...
> 
EhEh, nicely put... One day you'll have to explain me what is it that
you like in TBS (not not mention what is it that you like more in TBS
than in CBS!) :-P

Jokes apart, the point is not the algorithm, it's the approach. Resource
reservation is the only sane way to achieve good enough (soft and hard)
real-time scheduling in complex and dynamic virtualized environment
(where ARINC would fall short). A sane and a really simple (simple to
understand, simple to modify/augment, etc.) implementation of EDF is
indeed the best basic building block we could ever have for getting
there.

Once there, we will see about what specific budgeting algorithm to adopt
and if (and I don't see why not) and how to support more than just one.

The one thing I'd be really interested, would be RT-Xen people's opinion
(and I see Sisu is copied), as I'd love to see some collaboration
happening in here, especially in this phase, when we are basically
re-architecting the whole thing! :-)

Sisu?

> The parameters for the scheduler would be the budgeting algorithm, server
> budget, and the server period.  The parameters for the domains/vcpus would be
> domain/vcpu budget/timeslice and domain/vcpu period.
> 
That sounds a good plan. At some point, I think we want to have at least
a flag to flip on and off some kind of work conserving behavior...
something like the extratime we have right now, don't you Nate (and
Josh)?

That being said, I fully support Josh's and Nate's approach of
"simplifying first". Resource reservation scheduling algorithm,
especially in multiprocessor environment, are complex to get right.
Starting from something like we have right now, which wouldn't be that
good even in UP, and trying to fix it in a backward compatible way has,
if you ask me, no chance of being successful.

So, George, I guess the interface won't, in the long run, be that
different from what we have now. It's the implementation that will
change a great deal. And to come up with a sensible implementation, I
think Nate's proposed path is the best one to follow.

> Those are our ideas though and I know that Dario and others have ideas as well,
> so any feedback is appreciated.
> 
I'll comment on the patches, but the approach is the good one, and --let
me state this again-- it's wonderful to see someone stepping up to work
on it.

> In the short term, we are working on upstreaming a version of the CBS scheduler.
>  Dario mentored Josh Whitehead, who works with me, in implementing a crude
> version of it for his undergraduate project, so we are already half-way there.
> 
> http://wiki.xen.org/wiki/Archived/GSoC_2013#Temporal_Isolation_and_Multiprocessor_Support_in_the_SEDF_Scheduler
> 
Even more glad to see that work finally trying to find a way upstream!
Thanks again to both!

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel