[libvirt] [numatune PATCH v2] Support NUMA tuning

[Daniel Veillard]

On Sun, May 15, 2011 at 09:37:21PM -0400, Mark Wagner wrote:
> On 05/12/2011 06:45 AM, Daniel P. Berrange wrote:
> >On Thu, May 12, 2011 at 06:22:49PM +0800, Osier Yang wrote:
> >>Hi, All
> >>
> >>This series adopts Daniel's suggestion on v1, using libnuma but
> >>not invoking numactl to set the NUMA policy. Add support for
> >>"interleave" and "preferred" modes, except the "strict" mode
> >>supported in v1.
> >>
> >>The new XML is like:
> >>
> >><numatune>
> >>   <memory model="interleave" nodeset="+0-4,8-12"/>
> >><numatune>
> >>
> >>I persist in using the numactl nodeset syntax to represent
> >>the "nodeset", as I think the purpose of adding NUMA tuning
> >>support is to provide the use for NUMA users, keeping the
> >>syntax same as numactl will make them feel better.
> >
> >Compatibility with numactl syntax is an explicit non-goal.
> >numactl is just one platform specific impl.  Compatibility
> >with numactl syntax is of no interest to the ESX or VirtualBox
> >drivers. The libvirt NUMA syntax should be using other
> >existing libvirt XML as the design compatibility target.
> >
> 
> I won't argue semantic of XML with you, but please keep in mind
> that one of the main differences between using a numactl like
> mechanism and taskset is that the NUMA mechanisms also let you
> bind to specific, NUMA node memory, as well as specifying the
> access type.
> 
> So from the outside looking in, keeping things in terms of cpusets
> would seem to not be in full agreement with the RFE for NUMA support.
> I would think that the specification of NUMA binding would need to
> include NUMA nodes and specify memory bindings as well as the
> access type. From a performance perspective, support for true
> NUMA is what is the last hurdle that is keeping libvirt from being
> used in high performance situations.
> 
> I think that specifying things in terms of nodes instead of
> cpus will make it easier for the end user. So I guess I need
> to withdraw the part about not arguing XML...

  Hi Mark,

I'm not 100% sure I understand what you disagreeing with:
  - it seems to me that the proposed model does allow the specification
    of the nodes and the memory binding associated
  - I wonder if you just object to the "nodeset" attribute name here
  - please note that "Node" in the context of libvirt has the specific
    meaning of the whole physical machine http://libvirt.org/goals.html
    that terminology was set up 5 years ago and present in many places
    of the libvirt API. On the other hand "nodeset" is being used in
    other places to specify a set of cpu nodes in a NUMA context.

  Could you help us clarify your point of view ?

   thanks !

Daniel
-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/