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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On gio, 2014-07-17 at 06:12 -0400, Meng Xu wrote:

> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>ä2014å7æ16æææäå
> éï

>         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. 
> 
Agreed, and I'd go fo XEN_SCHEDULER_RT_DS. It means people have to learn
at least the basics of what _D_eferrable _S_erver means (which in turns
mean we must provide decent documentation! :-P), but if we want to go
for being specific, let's go there at full blast :-)

(and being specific means mentioning the actual algorithm, while GEDF is
sort of a 'basis', that many algorithms can share, and I don't think I
got what the 'P' in PGEDF stands for... did you perhaps mean
'PG'='Partitioned & Global'?)

> 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. 
> 
This is all true. However, I think I agree with Andrew and Konrad about
the need of being a bit more specific with naming.

Probably, I'd distinguish the name of the source file and the name of
the scheduling policy(ies). In fact, as you say, sched_rt.cc is probably
fine, as one may just implement new/different things hacking its
content, without the need of adding a new one.

At that point, you can well introduce, say, XEN_SCHEDULER_RT_CBS, which,
as far as the implementation is concerned, only modifies a function or
two in sched_rt.c, but for the user perspective, it's a different
scheduling policy, and it makes sense for it to have a different name.

Both (or more, if we like) scheduling policies may well even coexist,
share most of the code in sched_rt.c, and yet being two different
scheduling policies...

> 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. :-)
> 
As I said, it's always going to be an RT related scheduling policy so,
if the algorithm will be similar enough, it could be a first class
citizen inside sched_rt.c.

If we want to have more than a scheduling policy, we *need* names (of
the policies, not of the source file) to be specific.

The only downside of the specific name is if we at some point will want
to _replace_, rather than add, the DS algorithm with some other thing.
But even in that case, I don't think there will be much issues: at the
Xen level (not much compatibility requirements) we can just kill the old
and introduce the new. At the libxl level, we'll handle API stability in
the usual ways.

So, yes, I think I'm all for XEN_SCHEDULER_RT_DS implemented in
xen/common/sched_rt.c.

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: signature.asc
Description: This is a digitally signed message part

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