Add Vinod in this thread. Best Regards, Jason Liao
-----Original Message----- From: Adam Litke [mailto:ali...@redhat.com] Sent: 2014年3月19日 21:23 To: Doron Fediuck Cc: vdsm-devel; Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Martin Sivak; Gilad Chaplik; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Fwd: Question about MOM On 19/03/14 05:50 -0400, Doron Fediuck wrote: >Moving this to the vdsm list. > >----- Forwarded Message ----- >From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" ><chuan.l...@hp.com> >To: "Martin Sivak" <msi...@redhat.com>, ali...@redhat.com, "Doron >Fediuck" <dfedi...@redhat.com>, "Gilad Chaplik" <gchap...@redhat.com> >Cc: "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" ><shangchun.li...@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" ><xiao-lei....@hp.com> >Sent: Wednesday, March 19, 2014 11:28:01 AM >Subject: Question about MOM > >Hi All, > >I am a new with MOM feature. > >In my understanding, MOM is the collector both from host and guest and >set the right policy to KSM and memory ballooning get better >performance. Yes this is correct. In oVirt, MOM runs as another vdsm thread and uses the vdsm API to collect host and guest statistics. Those statistics are fed into a policy file which can create some outputs (such as ksm tuning parameters and guest balloon sizes). MOM then uses the vdsm API to apply those outputs to the system. >I am not sure how it has relationship with NUMA, does anyone can >explain it to me? I guess we need to start by examining the currently planned use cases. Please feel free to correct me if I am missing something or over-simplifying something: 1) NUMA-aware placement - Try to schedule VMs to run on hosts where the guest will not have to span multiple NUMA nodes. 2) Virtual NUMA topology - Emulate a NUMA topology inside the VM. These two use cases are intertwined because VMs with NUMA can be scheduled with more flexibility (albeit with more sophistication) since the scheduler can fit the VM onto hosts where the memory can be split across multiple Host NUMA nodes. 3) Manual NUMA pinning - Allow advanced admins to schedule a VM to run on a specific host with a manual pinning strategy. Most of these use cases involve the engine scheduler and engine UI. There is not much for MOM to do to support their direct implementation. We should focus on managing interactions with other SLA features that MOM does implement: - How should KSM be adjusted when NUMA is in effect? In a NUMA host, are there numa-aware KSM tunables that we should use? - When ballooning VMs, should we take into account how much memory we need to reclaim from VMs on a node by node basis? Lastly, let's see if MOM needs to manage the existing NUMA utilities in place on the system. I don't know much about AutoNUMA. Does it have tunables that should be adjusted or is it completely autonomous? Does libvirt have any NUMA tuning APIs that MOM may want to call to enhance performance in certain situations? One of the main questions I ask when trying to decide if MOM should manage a particular setting is: "Is this something that is set once and stays the same or is it something that must change dynamically in accordance with current system conditions?" In the former case, it is probably best managed by engine or vdsm directly. In the latter case, it fits the MOM model. Hope this was helpful! Please feel free to continue engaging this list with any additional questions that you might have. >On engine side, there is only one button with this feature: Sync MoM >Policy, right? > >On vdsm side, I saw the momIF is working for this, right? > >Best Regards, Jason Liao > -- Adam Litke [Jason] +Martin's part Hi, > In my understanding, MOM is the collector both from host and guest and > set the right policy to KSM and memory ballooning get better performance. Correct. MoM controls the Guest memory allocations using KSM and ballooning and allows overcommitment to work this way. I does not really set the policy thought, it contains the policy and uses it to dynamically update the memory space available for VMs. > I am not sure how it has relationship with NUMA, does anyone can explain it > to me? In theory MoM might be able to play with ballooning on per node basis. Without NUMA information it would free memory somewhere on the host, but that memory might be too slow to access because it won't be localized on nearby nodes. With NUMA information MoM will know which VMs can be ballooned so the newly released memory segments are a bit more closer to each other. > On engine side, there is only one button with this feature: Sync MoM Policy, > right? There is also Balloon device checkbox in the Edit VM dialog and Enable ballooning on the Edit Cluster dialog. > On vdsm side, I saw the momIF is working for this, right? Yes, momIF is responsible for the MoM specific communication and for creating the policy file with parameters. MoM also uses standard VDSM APIs to get other information and you can see that in MoM's source code in hypervisor_interfaces/vdsm (that interface is then used by collectors). Regards -- Martin Sivak msi...@redhat.com _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
