Xen project Mailing List

Hi Jan,

2014-08-27 11:04 GMT-04:00 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.

âYes, RT needs more fine grained control: it needs users to be able to set/get each VCPU's parameters. (This states RT scheduler needs such functionality of setting/getting each VCPU's parameters.)

âAs to your concern "I still don't see why such wouldn't be applicableÂuniformly to all schedulers."â, are you suggesting that the credit and credit2 scheduler could also allow users to set/get each VCPU's parameters? (I think that could be possible but this should be some design decision made by credit and credit2 scheduler developer?)

>> >> > +Â Â Â Â Â Â 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.

âHmm, that's fair. If we want to limit the range to seconds, then uint32 is enough. However, what if some user really want to set the period/budget to hours/days? Then we couldn't support it if we use uint32 type for period/budget. (This is just my subtle concern. I'm not arguing that we have to use uint64 or uint32. As long as everyone agrees with a type, I can just change it to the agreed type very quickly.) Do you have any suggestion of how we can reach an agreement and get the range finalized? â

âThank you very much for your time and help in this matter!

Best,

Mengâ

-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

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