Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of laszlo.hornyak@gmail.com
 designates 209.85.216.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKprHVbbeey2cU1Lq6ynfoqzOoZFnv1wsLS2+u7ne=N5q2Hvhg@mail.gmail.com>
References: 
 <CAKRHFXVEidyMn-nN=a36fWjsGp_zurJBzaU=p1P3wMfoJpxpXA@mail.gmail.com>
	<CAKprHVbbeey2cU1Lq6ynfoqzOoZFnv1wsLS2+u7ne=N5q2Hvhg@mail.gmail.com>
Date: Sun, 27 Apr 2014 23:25:59 +0200
Message-ID: 
 <CAKRHFXVqYwvMc5ShU2ETKsGMGzgBOTtBTh4UtOO+ebfSd=LYfg@mail.gmail.com>
Subject: Re: [PROPOSAL] KSM support for KVM hosts
From: Laszlo Hornyak <laszlo.hornyak@gmail.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=001a113ab05656493f04f80cd8a0

--001a113ab05656493f04f80cd8a0
Content-Type: text/plain; charset=UTF-8

Hi David,

The ksmd process takes quite some CPU time and keeps it at a constant level
even when it is no longer able to find new pages to merge. The trick the
dynamic configuration would do is to decide when is it safe to take some
CPU-time and spend it on decreasing memory usage. Since in the agent
(unlike in the linux kernel) we have access to information about this, I
have reason to believe that it is possible to avoid conflict between
household tasks and VM tasks in CPU.

A logical next step would be to modify the scheduler/orchestration to take
VM attributes in consideration and prefer similar VMs on the same host to
better operate with ksm.

Probably VMs could also gain from the same page merging, for example the
CPU cache misses could be less frequent if their pages are merged.

On Sun, Apr 27, 2014 at 5:08 PM, David Nalley <david@gnsa.us> wrote:

> On Sun, Apr 27, 2014 at 3:48 AM, Laszlo Hornyak
> <laszlo.hornyak@gmail.com> wrote:
> > Hi All,
> >
> > Currently Cloudstack does not manage the Linux Kernel SamePage Merger
> [1].
> > A KSM support would allow the operator of the cloud to gain high VM
> > densities in the cloudstack environment by merging the redundant memory
> > pages.
> >
> > 1. Add new configuration setting for KSM feature
> > - Ignore: Instructs agent to ignore KSM setting, this allows the cloud
> > operator to manage KSM and good for backward compatibility
> > - On: Instructs agents to turn on KSM without further dealing with it
> > - Off: Instructs agents to turn off KSM
> > - Dynamic: Instructs the agent to track KSM activity periodically, turn
> on
> > or off if needed and fine-tune runtime parameters based on its
> performance.
> >
> > 2. Build decision logic into cloudstack agent:
> > - Only enable KSM if running on Linux and KSM is built into kernel
> > - Dynamic KSM configuration decision logic:
> >   - Configure and tune KSM based on number of VM's, their operating
> > systems, the available and free processors and memory of the host.
> >   - The configuration and status of ksm needs to be checked periodically.
> >
> > In comparison to ksmtuned, the agent logic will build on information
> > specific to cloud computing
> >  - build on expectations based on the OS/template of the VM
> >  - scale dynamically with the VM loads
> >  - activate on VM migrations/start/stop
> >  - respect CPU over-allocation, run ksm only when low CPU-load
> >
> > [1] https://www.kernel.org/doc/Documentation/vm/ksm.txt
> >
> > --
> >
> > EOF
>
>
> Hi Laszlo;
>
> KSM has always seemed to have a high CPU overhead when I've used it in
> the real world. I am curious what you think the effect will be with
> dynamically turning it on/off and particularly how it might impact
> other VM operations as well as allocation decisions.
>
> --David
>


-- 

EOF

--001a113ab05656493f04f80cd8a0--