Re: [PATCH RFC v1 1/4] rt: Add rt scheduler to hypervisor

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Jul 17, 2014 at 06:12:22AM -0400, Meng Xu wrote:
> Hi Dario and Konrad,
> 
> First, thank you very much for your detailed and very useful comments on
> this patch! I'm modifying it based on your comments now. (I'm sorry I
> didn't reply promptly because I was in travel these days and cannot always
> get access to network. :-()

Hey,

CCing some of the DornerWorks folks.
> 
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>于2014年7月16日星期三写道：
> 
> > On Fri, Jul 11, 2014 at 05:48:17PM +0200, Dario Faggioli wrote:
> > > On ven, 2014-07-11 at 16:40 +0100, Andrew Cooper wrote:
> > > > On 11/07/14 16:21, Dario Faggioli wrote:
> > >
> > > > > So, ideas? RTDS (as per Real-Time Deferrable-Server)? RRESDS
> > (Resource
> > > > > Reservation Deferrable Server)? Just DS (Deferrable Server)?
> > > > >
> > > > > I'm not sure I like much any of these...
> > > > >
> > > > > What was it that you had in mind when you said "there are several
> > > > > classes of realtime schedulers employing different semantics and
> > > > > parameters" ?
> > >
> > > > Hmm - naming things is difficult.  How about bob?
> > > >
> > > Well, if we go that route, I prefer Alice! :-D :-D
> > >
> > > > My concern is that naming it "rt" seems too generic, and will cause
> > > > confusion of a) what type of realtime scheduler it is, and b) further
> > > > problems if someone wants to come and implement a different realtime
> > > > scheduler in the future.
> > > >
> > > Totally understood and agreed.
> > >
> > > > XEN_SCHEDULER_RT_DS doesn't sound too bad.
> > > >
> > > It does not, indeed. Let's hear Meng, Sisu, and the other xen-devel
> > > folks...
> >
> > DS9 :-)
> >
> > XEN_SCHEDULER_RT_PGEDF ?
> >
> > And then we can also have
> >  XEN_SCHEDULER_RT_CBS ?
> >
> >
> I see your concerns about the name here.
> The strength of the name you proposed, such as  XEN_SCHEDULER_RT_PGEDF or
> XEN_SCHEDULER_RT_DS, is that it clearly states the characteristics of this
> scheduler.
> 
> However, if people want to implement a new server mechanism for the EDF
> scheduling policy, they actually don't have to implement a fresh new one
> and add new sched_*.c files. They only need to modify the budget_update()
> and burn_budget() functions based on the new server mechanism. (Actually,
> we can make this scheduler more generic to make it easier to add a new
> server mechanism just as the schedule.c does.)
> 
> In addition, if people want to implement a new real-time scheduling policy,
> like Rate Monotonic scheduling, they only need to modify a few lines in
> sched_rt.c. (We actually had the Rate Monotonic scheduling already, but
> only extract the EDF one for Xen right now to avoid causing unnecessary
> confusion.)
> 
> So adding new server mechanisms and adding new scheduling policy (i.e.,
> priority schemes) only requires modify several functions in sched_rt.c,
> instead of creating a fresh new file and scheduler. If we use the too
> specific name, like XEN_SCHEDULER_RT_DS, we will have to modify the name in
> the future when we extend the scheduler.  Of course, we could also
> implement a fresh new scheduler, such as XEN_SCHEDULER_RT_CBS, or
> XEN_SCHEDULER_RT_PS (periodic server), in a brand new file, but it's
> actually unnecessary to introduce a new file.

Joshua, Robert, et. al,

Would it be feasible to rebase the core changes on top of this
file instead of using the SEDF?
> 
> Of course, I'm not against using the more specific name, such as
> XEN_SCHEDULER_RT_DS. What I'm concerned is: when we implement a new server
> mechanism or new scheduling policy inside the current sched_rt.c, the too
> specific name will become impropriate and we will have to change name
> again. :-)

Right.

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