Re: [Xen-devel] [PATCH v2 for Xen 4.6 1/4] xen: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Fri, May 29, 2015 at 2:51 PM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> wrote:
> On Mon, 2015-05-25 at 19:05 -0500, Chong Li wrote:
>
>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> index 28aea55..8143c44 100644
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -841,6 +841,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
>> u_domctl)
>>          copyback = 1;
>>          break;
>>
>> +    case XEN_DOMCTL_scheduler_vcpu_op:
>> +        ret = sched_adjust_vcpu(d, &op->u.scheduler_vcpu_op);
>> +        copyback = 1;
>> +        break;
>> +
>>
> So, thinking more about this, do we really want a full new DOMCTL, or do
> we want to instrument XEN_DOMCTL_scheduler_op? That would mean adding
> two operations there, and fiddling with struct xen_domctl_scheduler_op?
>
> The problem I see is that, whatever I imagine putting this, there would
> be some redundancy.
>
> Quick-&-dirty, I put together the below... would it possibly make sense?
>
> typedef struct xen_domctl_sched_credit {
>     uint16_t weight;
>     uint16_t cap;
> } xen_domctl_sched_credit_t;
>
> typedef struct xen_domctl_sched_credit2 {
>     uint16_t weight;
> } xen_domctl_sched_credit2_t;
>
> typedef struct xen_domctl_sched_rtds {
>     uint32_t
> period;
>     uint32_t budget;
> } xen_domctl_sched_rtds_t;
>
> typedef union xen_domctl_schedparam {
>     xen_domctl_sched_credit_t credit;
>     xen_domctl_sched_credit2_t credit2;
>     xen_domctl_sched_rtds_t rtds;
> } xen_domctl_schedparam_t;
>
> typedef struct xen_domctl_schedparam_vcpu {
>     union {
>         xen_domctl_sched_credit_t credit;
>         xen_domctl_sched_credit2_t credit2;
>         xen_domctl_sched_rtds_t rtds;
>     } s;
>     uint16_t vcpuid;
> } xen_domctl_schedparam_vcpu_t;
> DEFINE_XEN_GUEST_HANDLE(xen_domctl_schedparam_vcpu_t);
>
> /* Set or get info? */
> #define XEN_DOMCTL_SCHEDOP_putinfo 0
> #define XEN_DOMCTL_SCHEDOP_getinfo 1
> #define XEN_DOMCTL_SCHEDOP_putvcpuinfo 2
> #define XEN_DOMCTL_SCHEDOP_getvcpuinfo 3
> struct xen_domctl_scheduler_op {
>     uint32_t sched_id;  /* XEN_SCHEDULER_* */
>     uint32_t cmd;       /* XEN_DOMCTL_SCHEDOP_* */
>     union {
>         xen_domctl_schedparam_t d;
>         struct {
>             XEN_GUEST_HANDLE_64(xen_domctl_schedparam_vcpu_t) vcpus;
>             uint16_t nr_vcpus;
>         } v;
>     } u;
> };
> typedef struct xen_domctl_scheduler_op xen_domctl_scheduler_op_t;
> DEFINE_XEN_GUEST_HANDLE(xen_domctl_scheduler_op_t);
>
> I'm also attaching a (build-tested only) patch to that effect (I'm
> killing SEDF in there, so I don't have to care about it, as it's going
> away anyway).
>
> Thoughts?

After (finally) getting time to look at this series, I was going to
suggest something like this.

 -George

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