[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v1 1/4] xen: add real time scheduler rt



Hi Jan,


> +Â Â Â Â Â Â /* get vcpus' params */
> +Â Â Â Â Â Â XEN_GUEST_HANDLE_64(xen_domctl_sched_rt_params_t) vcpu;

Why does this need to be a handle? Do you permit setting these
to different values for different vCPU-s? Considering that other
schedulers don't do this, why does yours need to?

âYes, we need a handler here to get each vcpu's parameters of a domain.Â

let me explain why we need to set and get the parameters of "each" vcpu:
1) A VCPU is the basic scheduling and accounting unit in the Global Earliest Deadline First (gEDF) scheduling. We account the budget consumption for each vcpu instead of each domain, while the credit or credit2 scheduler account the credit consumption for each domain.Â
2) Based on the Global Earliest Deadline First (gEDF) scheduling theory, each vcpu's parameter will be used to decide the scheduling sequence of these vcpus. ÂTwo vcpus with same utilization but different period and Âbudget can be scheduled differently. For example, the vcpu with budget 10ms and period 20ms is less responsive than the vcpu with budget 2ms and period 8ms, although they have the same utilization 0.5. Â

Therefore, a domain's real-time performance is based on the parameters of each VCPU of this domain.Â
Hence, users need to be able to set and get each vcpu's parameters of a domain.

This gEDF scheduler is different from the credit and credit2 schedulers. The existing credit and credit2 scheduler account the credit for each domain, instead of each vcpu, that's why they set parameter per domain instead of per vcpu.

In my memory, we had such discussion on this question in the mailing list after the first RFC patch of this rt scheduler was released. We agreed that the real-time scheduler should supports setting and getting each vcpu's parameters. :-)
Â

> +Â Â Â Â Â Â uint16_t nr_vcpus;
> +Â Â Â Â Â Â /* set one vcpu's params */
> +Â Â Â Â Â Â uint16_t vcpu_index;
> +Â Â Â Â Â Â uint16_t padding[2];
> +Â Â Â Â Â Â uint64_t period;
> +Â Â Â Â Â Â uint64_t budget;

Are values overflowing 32 bits here really useful/meaningful?

âWâ
e allow the period and budget to be at most 31536000000000 (which is one year in microsecond) in the libxl.c. 31536000000000 is larger than 2^32 =4294967296. So we have to use 64bit type here for period and budget.

âIn addition, This is consistent with the period and budget type s_time_t in the kernel space. In the kernel space (sched_rt.c), we represent the period and budget in the type s_time_t, which is signed 64bit. So we use the uintâ64_t for period and budget here to avoid some type conversion. Â

Thank you very much for your time, comment and advice in this patch!

Best,

Meng



-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.