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

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



On sab, 2014-07-12 at 14:16 -0400, Meng Xu wrote:

> 
>         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)
> 
In libxc, you probably should transition to uint64_t, yes.

In libxl, you probably will have to use 'integer', as sedf does:
libxl_domain_sched_params = Struct("domain_sched_params",[
    ("sched",        libxl_scheduler),
    ("weight",       integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT'}),
    ("cap",          integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
    ("period",       integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
    ("slice",        integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
    ("latency",      integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
    ("extratime",    integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
    ])

> 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. 
> 
I concur. It's quite hard to decide what is a sane upper bound for
period and budget, as user may want to try doing all kind of crazy
stuff! :-O

For sure, if we want to put an upper bound, it has to come from some
reasoning about the scheduler's usage, rather than from limitations
coming from the actual type used (which makes sense, actually).

If, for instance, you keep 2^32 (no matter whether you use 32 or 64
bits), you end up with, if I've done the math correctly, a bit more than
1 hour period and budget, which I think is fine, do you?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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

 


Rackspace

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