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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

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?

>  /*
> - * set/get each vcpu info of each domain
> + * set/get per-domain params of a domain
>   */
>  static int
>  rt_dom_cntl(
> @@ -1115,6 +1115,74 @@ rt_dom_cntl(
>      return rc;
>  }
>  
> +/*
> + * set/get per-vcpu params of a domain
> + */
> +static int
> +rt_vcpu_cntl(
> +    const struct scheduler *ops,
> +    struct domain *d,
> +    struct xen_domctl_scheduler_vcpu_op *op)
> +{
>
I commented this function already, while replying to Jan.
 
> +/* Adjust scheduling parameter for the vcpus of a given domain. */
> +long sched_adjust_vcpu(
> +    struct domain *d,
> +    struct xen_domctl_scheduler_vcpu_op *op)
> +{
>
Actually, I don't think you even need this function.

Especially if we take the path of doing all this as subops of
DOMCTL_scheduler_op, you can just use sched_adjust, do some more
multiplexing in there, and the call the proper scheduler hook.

Thanks and 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)

Attachment: vcpuparams.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part

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