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

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant



>>> On 09.03.18 at 17:30, <george.dunlap@xxxxxxxxxx> wrote:
> On 03/09/2018 04:25 PM, Jan Beulich wrote:
>>>>> On 09.03.18 at 17:17, <olaf@xxxxxxxxx> wrote:
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -137,6 +137,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t);
>>>  #define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>>>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>>>  
>>> +#define XEN_GETPAGEFRAMEINFO3_MAX_SIZE 1024U
>> 
>> This is an implementation detail; it shouldn't be made part of the
>> public interface. If there's a need for user land to know the value,
>> and if there's currently no way to query it, that's what you
>> would want to add.
> 
> But the domctl interface isn't stable, right?  There's no need to make a
> flexible backwards-compatible interface between libxc and Xen; sharing a
> #define should be fine, as long as there's only one place to change it.

Well, strictly speaking this is an option. But I would prefer if we didn't
abuse the "is not a stable interface" property, which this changes
feels like it would. 

Furthermore it hasn't become clear to me why, if this hard coded
number is deemed a problem, we don't get rid of it altogether.
Domctl-s have long gained the ability to be preemptible - there
various examples.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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