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

Re: [Xen-devel] [PATCH v6 1/5] sysctl: Make XEN_SYSCTL_numainfo a little more efficient



>>> On 07.04.15 at 18:57, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 04/07/2015 12:04 PM, Andrew Cooper wrote:
>> On 06/04/15 23:12, Boris Ostrovsky wrote:
>>> A number of changes to XEN_SYSCTL_numainfo interface:
>>>
>>> * Make sysctl NUMA topology query use fewer copies by combining some
>>>    fields into a single structure and copying distances for each node
>>>    in a single copy.
>>> * NULL meminfo and distance handles are a request for maximum number
>>>    of nodes (num_nodes). If those handles are valid and num_nodes is
>>>    is smaller than the number of nodes in the system then -ENOBUFS is
>>>    returned (and correct num_nodes is provided)
>>> * Instead of using max_node_index for passing number of nodes keep this
>>>    value in num_nodes: almost all uses of max_node_index required adding
>>>    or subtracting one to eventually get to number of nodes anyway.
>>> * Replace INVALID_NUMAINFO_ID with XEN_INVALID_MEM_SZ and add
>>>    XEN_INVALID_NODE_DIST.
>>>
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
>>> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> This subtly changes the behaviour of XEN_SYSCTL_numainfo with regards to
>> NULL guest handles.
>>
>> Previously, a caller was able to select which information they wanted by
>> choosing which guest handles were non-NULL.
>>
>> With the new semantics, the caller must pass both ni->meminfo and
>> ni->distance to get either bit of information.  Each
>> copy_to_guest_offset() should be gated on a !guest_handle_is_null() so a
>> caller can request meminfo information without distance information.
> 
> 
> Currently the caller, in fact, can have either of three pointers 
> (node_to_memsize, node_to_memfree or node_to_node_distance) as NULL and 
> the hypervisor will fill whichever pointer is valid. Because I put the 
> first two together into a struct we are already changing behavior in 
> that regard. Not to mention that having all three as NULL now has new 
> meaning as well.
> 
> I thought that either both pointers should be valid or neither. If 
> people disagree I can change this.

I agree with Andrew's view, fwiw.

Jan


_______________________________________________
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®.