On Tue, 2017-08-08 at 12:16 -0700, Meng Xu wrote: > On Tue, Aug 8, 2017 at 9:09 AM, Dario Faggioli > <dario.faggi...@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)
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xen.org/xen-devel