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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 03/09/2018 04:43 PM, Jan Beulich wrote:
>>>> 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.

Yes, making it preemptible and removing the limit is probably a better
option.

 -George

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