Re: Adding Memory Overcommitment Manager (MOM) to oVirt

From: "Alexander Graf" <agraf(a)suse.de&gt; To: "Ayal Baron" <abaron(a)redhat.com&gt; Cc: &quot;&lt;board(a)ovirt.org&gt;&quot; <board(a)ovirt.org&gt; Sent: Tuesday, September 27, 2011 3:28:29 AM Subject: Re: Adding Memory Overcommitment Manager (MOM) to oVirt Am 27.09.2011 um 08:56 schrieb "Ayal Baron" <abaron(a)redhat.com&gt;: > > > ----- Original Message ----- >> On 09/27/2011 12:52 AM, Adam Litke wrote: >>>>> First of all I think this is great! Thanks Adam! >>>>> Wrt the question above, the way I see vdsm going forward is a >>>>> lot more policy >>>>> management, especially once we start talking about SLAs. This >>>>> will involve a >>>>> lot more than just memory policies, and although I may be >>>>> impartial here, I >>>>> think that this should fall under vdsm or under a policy engine >>>>> project >>>>> (bigger scope than just memory) which vdsm would use. To >>>>> elaborate, in >>>>> addition to memory, we need to manage policies around network, >>>>> storage and cpu >>>>> and manipulate cgroups, tc, page cache etc. If we take page >>>>> cache as an >>>>> example, it affects memory on the machine hence, MOM would like >>>>> to tweak it >>>>> (also in the preso), but we already have recent results from >>>>> the perf team to >>>>> change the defaults here to significantly increase I/O >>>>> throughput, improve >>>>> fairness and reduce effect of buffered writers on VMs and we >>>>> know that going >>>>> forward we'll have to tweak these parameters dynamically to >>>>> adjust to varying >>>>> workloads, esp if we ever plan on making good the claim for a >>>>> hybrid server. >>>>> Having separate projects tweaking the same params will not lead >>>>> to good >>>>> results. >>> Ayal, I definitely agree. I must admit that the project name MOM >>> (while a nice >>> acronym), implies a restricted scope (memory only) but the >>> architecture of MOM >>> does not limit its functionality to memory tuning only. I assert >>> that MOM can >>> easily become the policy engine piece that you are speaking of. >>> >>> The framework is very extensible (a set of Collectors that expose >>> system state, >>> a set of Controllers that expose "tuning knobs", and a policy >>> that >>> reads >>> the state and manipulates the knobs. Adding control for cgroups >>> is >>> as simple as >>> writing a cgroups Collector and Controller. >> >> It would be nice to agree on the initial (more limited scope >> maybe) >> for >> the code within vdsm so the work be able to be done soonish. Since >> vdsm >> is a relevantly a new open source project there will be many >> future >> changes and imho there is no need to wait for the perfect policy >> engine >> framework. >> > > The project can initially contain only memory management, that is > not an issue whatsoever. > But the project mission should be correct from the start so that > design decisions are made with the full picture in mind. Let me try to grasp the full picture here. VDSM is basically the 'node controller', managing all active VMs on a system, correct? So this is the instance that watches things on node granularity. MOM watches resources on node granularity, interacting only with vdsm and the VM(?) to manage overcommit of memory. Why should this be separate from VDSM? Does it buy us anything as a separate project? Is the interface cut here helpful in any way? I don't want to see 50 separate daemons that in reality are a single entity but have to be artificially maintained separate, because someone thought it's nice to split things into projects instead of submodules of a project. So what's the benefit of a separate MOM vs an integrated MOM inside of VDSM?

Alex _______________________________________________ Board mailing list Board(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/board