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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-04-13 at 16:52 +0100, Jan Beulich wrote:
> >>> 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.

So do I, although I wouldn't revoke my ack (which I would normally have
intended to make conditional on the h/v guys being happy, but it seems I
didn't remember on v5).

Ian



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