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 allocationHere 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
-- 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]