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

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? Dave > Bill > >> Regards, >> Osier >