Xen project Mailing List

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. :-()

Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>ä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.Â

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. :-)

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