[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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


And then we can also have

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




Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.