[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
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@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. 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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |