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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.08.14 at 16:28, <xumengpanda@xxxxxxxxx> wrote:
> Because each vcpu's parameters can affect the scheduling sequence and thus
> affect the real-time performance of a domain, users may want to know what
> is the parameters of each vcpu of each domain so that they can have an
> intuition of how the vcpus will be scheduled.  (Do you agree? :-))

I agree, but that isn't a specific property of this scheduler, just
one of it's specific intended use (RT).

> Users may also need to set each VCPU's parameter of a domain to achieve
> their desired real-time performance for this domain. After they set a
> vcpu's parameter of a domain, they need to have a way to check the new
> parameters of this vcpu of this domain. right?

Of course.

> We had a long discussion of the design of this functionality of getting
> each vcpu's parameters. It's here:
> http://www.gossamer-threads.com/lists/xen/devel/339146 

This thread doesn't discuss this at all - Dario takes it for given in
his first reply: "My view here is, since per-VCPU scheduling
parameters are important for this scheduler, ..."

> Another thread that discusses the interface for improved SEDF also
> discusses the idea of getting/setting each vcpu's parameters for a
> real-time scheduler.  This rt scheduler is supposed to replace the existing
> SEDF scheduler.
> 
> Here is the link to this thread:
> http://www.gossamer-threads.com/lists/xen/devel/339056 

Again this one more states than discusses the need.

> I extract the interesting part related to this question:
> Quote from Dario
> :
> 
> 
> "I don't
> think the renaming+SEDF deprecation should happen until proper SMP
> support is implemented, and probably also not until support for per-VCPU
> scheduling parameters (quite important for an advanced real-time
> scheduling solution) is there."

That doesn't directly relate to the question I raised, it's more like a
follow-up assuming that per-vCPU parameters are needed here,
but not in other schedulers.

So bottom line - While I realize that RT may desire more fine
grained control, I still don't see why such wouldn't be applicable
uniformly to all schedulers.

>> >> > +            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 uint64_t for period and budget here to avoid some type conversion.
>>
>> Neither of this answers the question: Is this really a useful value
>> range?
>>
> 
> I see the issue. Is 31536000000000 a good upper bound for period and
> budget?
> Actually, I'm not sure. This totally depends on users' requirement.
> 4294967296us = 1.19hour. I'm not sure 1.19hour should be long enough for
> real-time applications?
> If it's enough, I can definitely change the type from uint64 to uint32.
> Do you have any suggestion of how we can get a proper upper bound for
> period and budget?

I think anything going into the seconds, not to speak of minutes or
hours, range is already beyond boundaries of being reasonable /
useful.

Jan


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