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

Re: [libvirt] [PATCH RFC]: Support numad



On 02/28/2012 11:34 PM, Osier Yang wrote:
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"/>


Please keep Bill Gray on this thread. He is the author of numad and
is the best person to answer the above questions.

 Bill

Regards,
Osier


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