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

[Chong Li <lichong659@xxxxxxxxx>]

On Tue, Mar 15, 2016 at 11:41 AM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> wrote:
> On Tue, 2016-03-15 at 11:22 -0500, Chong Li wrote:
>> On Mon, Mar 14, 2016 at 5:05 AM, Dario Faggioli
>> <dario.faggioli@xxxxxxxxxx> wrote:
>> >
>
> We said 'once' and then 'once per domain', but something I'd be fine
> with (coupled with keeping G_WARNING) would be 'once per operation'.
> Basically, if a domain has 128 vcpus, and an hypercall tries to set all
> of them to period=100, budget=50, we just print the warning once. Then,
> if after a while the sysadmin tries the same again, we again just log
> once, etc.
>
> Doing this seems much easier, as the 'warned' flag could just be a
> local variable of the hypercall implementation. I'm quite sure that
> would work if there is not any continuation/re-issueing mechanism in
> the hypercall in question. BUT in our case there is, so things may be
> more complicated... :-/
>
> Had you thought about a solution like this already? If no, can you see
> whether there is a nice and easy way to make something like what I just
> described above to work in our case?
>
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;

Chong



-- 
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis

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