[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
>>> On 27.08.14 at 04:07, <xumengpanda@xxxxxxxxx> wrote: >> > + /* 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. Parameter setting and accounting aren't tied together, and both credit schedulers account on a per-vCPU basis afaict. Hence this doesn't really answer the question. > 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. :-) If so, can you point me to the specific mails rather than have me go dig for them? >> > + 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. Neither of this answers the question: Is this really a useful value range? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |