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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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