Google
  Web www.spinics.net

Re: [PATCH RFC]: Support numad

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


On 03/01/2012 02:31 PM, Dave Allan wrote:
On Wed, Feb 29, 2012 at 06:29:55AM -0500, Bill Burns wrote:
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 (Gray),

Can you weigh in here?
Am sure he will, but he is on PTO, back sometime over
the weekend, Monday at the latest ;-)

the other Bill


Dave

  Bill

Regards,
Osier

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Virt Tools]     [Libvirt Users]     [Fedora Users]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

Powered by Linux

Google
  Web www.spinics.net