[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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




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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.