Re: [PATCH RFC v1 3/3] xl: enable per-VCPU work conserving flag for RTDS

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3564 bytes --]

On Thu, 2017-08-03 at 18:02 -0400, Meng Xu wrote:
> On Thu, Aug 3, 2017 at 12:03 PM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > 
> > > @@ -702,14 +705,18 @@ int main_sched_rtds(int argc, char **argv)
> > >      int *vcpus = (int *)xmalloc(sizeof(int)); /* IDs of VCPUs
> > > that
> > > change */
> > >      int *periods = (int *)xmalloc(sizeof(int)); /* period is in
> > > microsecond */
> > >      int *budgets = (int *)xmalloc(sizeof(int)); /* budget is in
> > > microsecond */
> > > +    int *workconservings = (int *)xmalloc(sizeof(int)); /*
> > > budget is
> > > in microsecond */
> > > 
> > 
> > Yeah, budget is in microseconds. But this is not budget! :-P
> 
> Ah, my bad..
> 
> > 
> > In fact (jokes apart), it can be just a bool, can't it?
> 
> Yes, bool is enough.
> Is "workconserving" too long here?
> 
So, I don't want to turn this into a discussion about what colour we
should paint the infamous bikeshed... but, yeah, I don't especially
like this name! :-P

An I mean, not only here, but everywhere you've used it (changelogs,
other patches, etc.).

There are two reasons for that:
 - it's indeed very long;
 - being work conserving is (or at least, I've always heard it used 
   and used it myself) a characteristic of a scheduling algorithm (or 
   of its implementation), *not* of a task/vcpu/schedulable entity.

   It is the scheduler that is work conserving, iff it never let CPUs
   sit idle, when there is work to do. In our case here, the scheduler
   is work conserving if all the vCPUs has this flag set. It's not,
   if even just one has it clear.

   And by putting workconserving-ness at the vCPU level, it looks to
   me that we're doing something terminologically wrong, and 
   potentially confusing.

I didn't bring this up before, because I'm a bit afraid that it's just
be being picky... but since you mentioned this yourself.

> I thought about alternative names, such as "wc", "workc", and
> "extratime". None of them is good enough.
>
Yep, I agree that contractions like 'wc' or 'workc' are pretty bad.
'extratime', I'd actually like it better, TBH.

> The ideal one should be much
> shorter and easy to link to "work conserving". :(
> If we use "extratime", it may cause confusion with the "extratime" in
> the depreciated SEDF. (That is my concern of reusing the EXTRATIME in
> the libxl_type.idl.)
> 
Well, but SEDF being gone (and since quite a few time), and the fact
that RTDS and SEDF have not really never been there together, does
leave very few room for confusion, I think.

While in academia (e.g., in the GRUB == Gready Reclaming of Unused
Bandwidth papers), what you're trying to achieved, I've heard it called
'reclaiming' (as I'm sure you have as well :-)), and my friends that
are still working on Linux, are actually using it in there:

https://lkml.org/lkml/2017/5/18/1128
https://lkml.org/lkml/2017/5/18/1137 <-- SCHED_FLAG_RECLAIM

I'm not so sure about it... As I'm not sure the meaning would appear
obvious, to people not into RT scheduling research.

And even from this point of view, 'extratime' seems a lot better to me.
And if it were me doing this, I'd probably use it, both in the
internals and in the interface.

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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