Re: [Xen-devel] [PATCH RFC v1 4/4] libxc for rt scheduler

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

An unrelated thing, can you set your mail client to send text message,
instead of HTML ones?

On ven, 2014-07-11 at 12:23 -0400, Meng Xu wrote:


>         My view here is, since per-VCPU scheduling parameters are
>         important for
>         this scheduler, you either:
>          - provide an interface for getting and setting the parameters
>         of _one_
>            _VCPU_, and the call them repeatedly, if for instance you
>         need to act
>            on a domain. In this case, no array and no bouncing should
>         be
>            necessary.
>          - provide both the above, and another interface, that one
>         with an array
>            as big as the number of VCPUs of the domain, and use it to
>         provide
>            the hypervisor with the parameters of all the VCPUs, and
>         act
>            appropriately inside Xen.
>         
>         Personally, I'd start with the former, and add the latter
>         later, if we
>         deem it necessary.
> 
> 
> Actually, we did the former one in the very early version of the rt
> scheduler. The only concern I have about the former version is that it
> has to issue the hypercall for many times to get all VCPUs'
> information of a domain, while the later one only issue the hypercall
> once with bouncing. 
> 
True. However, if you only want to get or set one particular vcpu, it's
annoying to have to deal with the array, isn't it?

So, both solutions have up and down sides, depending on what you
actually need. :-)

This is why I was suggesting to implement both. Of course, it does not
matter much which one you implement first. Se, feel free to implement
the array variant properly first, and then we'll see if we also need the
single VCPU variant.

> My concern is: Will the former one has worse performance than the
> later one?  â
> 
Well, Xen has its tricks, but yes, I think performing e.g., 8 or 16
hypercalls in a loop is worse than issueing one returning an array.

It also must be noted that, getting and setting scheduling parameters,
should not happen in very critical path, so it probably won't matter
much.

Anyway, as said above, go for the array first if you like it better.
When you do that, consider Andrew's comments to the bottom of patch 1:

"As a gut feel, I think that these two ints should be part of the struct
xen_domctl_sched_rt below, with a guest handle pointing to an array of {
period, budget } structures, which avoids the LEGACY_MAX limit."

I don't think you'll need vcpu_index any longer, and I'm not sure
whether you need max_vcpus to be part of the interface of this hcall, or
if you're better out fetching it from some other call, though.

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: signature.asc
Description: This is a digitally signed message part

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