cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [PROPOSAL] KSM support for KVM hosts
Date Sun, 27 Apr 2014 15:08:50 GMT
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

Mime
View raw message