Adding Memory Overcommitment Manager (MOM) to oVirt

[Andrew Cathrow]

----- Original Message -----
> From: "Alexander Graf" <agraf at suse.de>
> To: "Ayal Baron" <abaron at redhat.com>
> Cc: "<board at ovirt.org>" <board at ovirt.org>
> 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 at redhat.com>:
> 
> > 
> > 
> > ----- 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?

I'd agree this is really VM policy which should be handled by VDSM.

> 
> 
> Alex
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board
>