Re: [Xen-devel] [PATCH RFC v1 3/4] libxl for rt scheduler

[Meng Xu <xumengpanda@xxxxxxxxx>]

Hi Dario,

Â

> + Â Âif ( !scinfo->rt.vcpus ){
> + Â Â Â ÂLOGE(ERROR, "Allocate lib_vcpu array fails\n");
> + Â Â Â Âreturn ERROR_INVAL;
> + Â Â}
> + Â Âscinfo->rt.num_vcpus = sdom.num_vcpus;
> + Â Âfor( i = 0; i < sdom.num_vcpus; ++i)
> + Â Â{
> + Â Â Â Âscinfo->rt.vcpus[i].period = sdom.vcpus[i].period;
> + Â Â Â Âscinfo->rt.vcpus[i].budget = sdom.vcpus[i].budget;
> + Â Â}
> +
> + Â Âreturn 0;
> +}
> +
> +#define SCHED_RT_VCPU_PARAMS_MAX Â Â4294967295 /* 2^32-1 */
> +
I don't like the name. I'd go for something like
SCHED_RT_VCPU_PERIOD_MAX and SCHED_RT_VCPU_BUDGET_MAX.

I will modify this.Â

Â

You well can define both to the same value, of course.

As per the value, yes, even if we turn the interface in usecs, 2^32
usecs is still ~4000 secs, which ought to be enough as a period or
budget for everyone! :-)

Actually, I'm not very sure about the range (max value) for the xl sched-rt interface now: I will change the type of period and budget in Xen to s_time_t which is signed long (64bits). (I can also change the type of period and budget in tool to be 64bits)

My question is:

Do we really need to do this range check and set the max value of the xl sched-rt to (2^64 - 1)/1000 (us)? (64 bits can have 2^61-1 ns, so it's (2^64-1)/1000 us)

If we look at the actually range value (2^64-1)/1000 ns, it's equal to 5.8*10^11 years, which is too large to be realistic.Â

Thanks,

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