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 > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list