[libvirt] [PATCH RFC]: Support numad

Osier Yang jyang at redhat.com
Wed Feb 29 04:34:13 UTC 2012

On 02/29/2012 12:40 AM, Daniel P. Berrange wrote:
> On Tue, Feb 28, 2012 at 11:33:03AM -0500, Dave Allan wrote:
>> On Tue, Feb 28, 2012 at 10:10:50PM +0800, Osier Yang wrote:
>>> numad is an user-level daemon that monitors NUMA topology and
>>> processes resource consumption to facilitate good NUMA resource
>>> alignment of applications/virtual machines to improve performance
>>> and minimize cost of remote memory latencies. It provides a
>>> pre-placement advisory interface, so significant processes can
>>> be pre-bound to nodes with sufficient available resources.
>>> More details: http://fedoraproject.org/wiki/Features/numad
>>> "numad -w ncpus:memory_amount" is the advisory interface numad
>>> provides currently.
>>> This patch add the support by introducing new XML like:
>>>    <numatune>
>>>      <cpu required_cpus="4" required_memory="524288"/>
>>>    </numatune>
>> Isn't the usual case going to be the vcpus and memory in the guest?
>> IMO we should default to passing those numbers to numad if
>> required_cpus and required_memory are not provided explicitly.
> Indeed, why you would want to specify anything different ? At
> first glance my reaction was just skip the XML and call numad
> internally automatically with the guest configured allocation

Here the "required_cpus" stands for the physical CPUs number,
which will be used numad to choose the proper nodeset. So from
sementics point of view, it's different with <vcpus>4</vcpus>,
I can imagine two problems if we reuse the vCPUs number for
numad's use:

1) Suppose there are 16 pCPUs, but the specified vCPUs number
is "64". I'm not sure if numad will work properly in this case,
but isn't it a bad use case? :-)

2) Suppose there are 128 pCPUs, but the specified vCPUs number
is "2". numad will work definitely, but is that the result the
user wants to see? no good to performace.

The basic thought is we provide the interface, and how to configure
the provided XML for good performace is on the end-user then. If
we mixed-use the two different sementics, and do things secrectly
in the codes, then I could imagine there will be performance problems.

The "required_memory" could be omitted though, we can reuse
"<memory>524288</memory>", but I'm not sure if it's good to
always pass a "memory amount" to numad command line, it may be
not good in some case. @Bill(s), correct me if I'm not right. :-)

Perhaps we could have a bool attribute then, such as:

<cpu required_cpus="4" required_memory="yes|no"/>


More information about the libvir-list mailing list