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

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

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

On Tue, 2017-08-08 at 12:16 -0700, Meng Xu wrote:
> On Tue, Aug 8, 2017 at 9:09 AM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > On Sun, 2017-08-06 at 22:43 -0400, Meng Xu wrote:
> > > 
> > > As to (1), if users want to set some VCPUs with extratime flag
> > > set
> > > and
> > > some with extratime flag clear, there are two types of input:
> > > (a) xl sched-rtds -d 1 -v 1 -p 10000 -b 4000 -e 0 -v 2 -p 10000
> > > -b
> > > 4000 -e 1 -v 5 -p 10000 -b 4000 -e 0
> > > (b) xl sched-rtds -d 1 -v 1 -p 10000 -b 4000 -v 2 -p 10000 -b
> > > 4000 -e
> > > 1 -v 5 -p 10000 -b 4000
> > > I felt that the style (a) is more intuitive and the input
> > > commands
> > > have very static pattern, i.e., each vcpu must have -v -p -b -e
> > > options set.
> > > 
> > 
> > Exactly, I do think that (b) is indeed a better user interface.
> > 
> With the approach (b), what I have in my mind was: if users do not
> use
> -e option for a vcpu index, the vcpu will have its extratime flag
> cleared.
> If not-setting -e option for a VCPU means using the current extratime
> value for the VCPU, then how should users clear the extratime flag
> for
> a VCPU? 
>
Yeah, I know... Well, it's an hard interface to get right.

So, I think, considering how things currently work for budget and
period, I guess I'm fine with the -e switch taking a 0/1 value.

I've checked how it was in SEDF, and it was like that in there too
(see, e.g. commit 1583cdd1fdded49698503a699c5868643051e391).

> If you look at the -p and -b option for the xl sched-rtds, we will
> find that users will have to first read both parameters of a VCPU
> even
> if they only want to change the value for one parameter, either -p or
> -b. We don't allow users to specify -p or -b without an input value.
> 
Yes. Which I now remember as something I've never really liked. But
again, it's an interface which is a bit hard to get right. And it's
certainly not this patch series' job to change it.

So, let's stick with it. Thanks for bearing with me. :-)


I now want to bring something new on the table, though: what should the
default be?

I mean, what do we expect most people to want, e.g., at domain creation
time, if they don't include an 'extratime=1' in their config file
(actually, I don't think it's even possible to do that! :-O) ?

I believe that --kind of unlikely wrt what happens in the real-time
research and papers-- most users would expect a work conserving
scheduler, unless they specify otherwise.

As in, they hopefully will enjoy being able to reserve some CPU
bandwidth in a very precise and deterministic way, for their vCPUs. But
I don't think they see as a good thing the fact that those vCPUs stops
running at some point, even if the system is idle.

Also, I think we really should set dom0 to be in extratime mode.

Therefore, I think I would set extratime as on by default in both Xen
an xl. What do you think?

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 #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