Re: [Xen-devel] [RFC Patch 1/3] Remove sedf extra, weight, and latency parameter support.

[Nate Studer <nate.studer@xxxxxxxxxxxxxxx>]

On 3/21/2014 7:16 AM, Ian Campbell wrote:
> On Fri, 2014-03-14 at 15:13 -0400, Nathan Studer wrote:
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> old mode 100644
>> new mode 100755
>> index 4c9cd64..6be5575
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -1093,8 +1093,6 @@ int libxl_sched_credit_params_set(libxl_ctx *ctx, 
>> uint32_t poolid,
>>  #define LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT       -1
>>  #define LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT    -1
>>  #define LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT     -1
>> -#define LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT   -1
>> -#define LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT -1
>>  
>>  int libxl_domain_sched_params_get(libxl_ctx *ctx, uint32_t domid,
>>                                    libxl_domain_sched_params *params);
> [...]
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> old mode 100644
>> new mode 100755
>> index 7d3a62b..1265a73
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -291,8 +291,6 @@ libxl_domain_sched_params = 
>> Struct("domain_sched_params",[
>>      ("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'}),
>>      ])
>>  
>>  libxl_domain_build_info = Struct("domain_build_info",[
> 
> We need to do something about ABI compatiblity here. Please see the
> comments near the top of libxl.h.
> 
> If you were adding new features, or even if replacing, then the obvious
> answer would be LIBXL_HAVE_NEW_SCHED_THING (which would imply removal of
> the old).
> 
> If you intend in a future non-RFC version of this series to do something
> like that then we can follow that path at that time.

Thanks for the information Ian.

This is the intention, so we would prefer the LIBXL_HAVE_NEW_SCHED_THING path.
It seems cleaner.

We just wanted to make sure that there were no major objections to re-purposing
the sedf scheduler before we went too far down that path, and so far we have not
seen anybody step up to defend the sedf scheduler.

    Nate
> 
> Otherwise two options come to mind:
>       #define LIBXL_HAVE_NO_SCHED_SEDF_{LATENCY,EXTRATIME}
> or
>       #define LIBXL_HAVE_SCHED_SEDF_V2
> 
> I think I vaguely prefer the first.
> 
> Ian.
> 


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