You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Laszlo Hornyak <la...@gmail.com> on 2014/04/27 09:48:12 UTC
[PROPOSAL] KSM support for KVM hosts
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
Re: [PROPOSAL] KSM support for KVM hosts
Posted by Laszlo Hornyak <la...@gmail.com>.
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 <da...@gnsa.us> wrote:
> On Sun, Apr 27, 2014 at 3:48 AM, Laszlo Hornyak
> <la...@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
Re: [PROPOSAL] KSM support for KVM hosts
Posted by David Nalley <da...@gnsa.us>.
On Sun, Apr 27, 2014 at 3:48 AM, Laszlo Hornyak
<la...@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