Re: [PATCH v6 for Xen 4.7 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler

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

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

On Tue, 2016-03-15 at 23:43 -0400, Meng Xu wrote:
> On Tue, Mar 15, 2016 at 11:32 PM, Chong Li <lichong659@gmail.com>
> wrote:
> > > > How about:
> > > > 
> > > > We create a global variable in sched_rt.c:
> > > >     /* This variable holds its value through hyerpcall re-
> > > > issueing.
> > > >      * When finding vcpu settings with too low budget or period
> > > > (e.g,
> > > > 100 us), we print a warning
> > > >      * and set this variable "true". No more warnings are
> > > > printed
> > > > until this variable
> > > >      * becomes false.
> > > >      */
> > > >     static bool warned;
> > > > Initialize it as "false" in rt_init().
> > > > In your example,
> > > > we "warned = true" when we find the first vcpu has budget less
> > > > than
> > > > 100 us. Outside
> > > > of the while loop, we do:
> > > >     if ( index == op->u.v.nr_vcpus ) /* no more hypercall re-
> > > > issueing */
> > > >         warned = false;
> > > > 
> > > 
> > > 
> > If we define
> > 
> >    static bool warned;
> > 
> > at the beginning of rt_dom_cntl(), do we need to initialize it? If
> > without
> > initialization, I think its default value is "false", which is just
> > what we need.
> > 
> We need initializing any variable we are going to use, of course. We
> should not reply on the compiler to give an initialized value. :-)
>
We need to initialize any variable that would be used uninitialized, if
we don't initialize it. :-)

However, something along the line of a static variable was also what I
was thinking to, but I don't think it works sufficiently well for
justifying it being introduced. And making things work well is proving
to be too hard to keep bothering.

Reasons why I'm saying I don't think it works well are that: (a) there
may be more than one CPU executing this hypercall, and they'd race on
the value of the static flag; (b) what if the hypercall finishes
processing the first lot of 64 vCPUs with the flag set to false, are we
sure it can't be anything than "still false", when the new hypercal,
for the next lot of vCPUs of the same domain, is re-issued?

I continue to think that it could be useful to have this logged, but
I'm leaning toward just killing it for now (and maybe finding another
way to check and warn about the same thing or one of the effects it
produces, later).

Meng, what do you think?



> 
> Meng
-- 
<<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: 181 bytes --]

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

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