Hi Marcus, KSM or memory de-duplication on KVM can only be used when the memory pages are identical. IMO this is a huge constraint which is true only for specific use cases. using KSM to implement overprovisioning will limit this feature to a specific use case and hence memory ballooning was chosen which is more generic.
Thanks, Bharat. On 28-Jan-2014, at 11:58 am, Marcus Sorensen <shadow...@gmail.com> wrote: > Yeah, I'm a little disappointed that the functional spec doesn't > really address memory deduplication, which is the real version of > overcommit, IMO. Since it looks like the feature is already fully > implemented, I'm not sure I have much of a leg to stand on in trying > to change it. I'll just patch it out of our builds. Thanks for the > input. > > On Mon, Jan 27, 2014 at 11:13 PM, Bharat Kumar <bharat.ku...@citrix.com> > wrote: >> Hi Marcus, >> >> in case of KVM the guest memory is not dynamically adjusted by hypervisor, >> this is a hypervisor limitation. we have documented this in the FS in >> prerequisites for KVM. >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit >> >> One way to make this work automatically is to use a script to monitor the >> memory pressure in the guest VM and adjust the memory using cgroups. >> one such script is Memory over commit manager. >> more info here >> http://aglitke.wordpress.com/2011/03/03/automatic-memory-ballooning-with-mom/ >> >> Thanks, >> Bharat. >> >> >> >> On 28-Jan-2014, at 11:23 am, Marcus Sorensen >> <shadow...@gmail.com<mailto:shadow...@gmail.com>> wrote: >> >> Yeah, that's not overprovisioning, though. That's scaling. The way >> it's implemented now is just ... provisioning. It allocates exactly >> what's available at the host. >> >> Also, the vm in your example can't go to 4GB. There is nothing that >> changes it's 'currentMemory' setting. Without a scaling feature it's >> simply always stuck at 2GB. >> >> On Mon, Jan 27, 2014 at 10:32 PM, Harikrishna Patnala >> <harikrishna.patn...@citrix.com<mailto:harikrishna.patn...@citrix.com>> >> wrote: >> Hi, >> I think the way it was done is to guarantee minimum memory to that VM and >> upon demand it can get upto the memory defined in service offering. >> Say a vm with service offering 4Gb is deployed with overprovisioing factor >> 2, we guarantee that vm should get minimum of 2GB (4GB/2) and if that VM is >> overloaded then it can get memory unto max 4GB. >> This is what it is showing vm definition >> <memory unit='KiB’>4GB</memory> >> <currentMemory unit='KiB’>2GB</currentMemory> >> "memory unit” is what it can get maximum. >> >> -Harikrishna >> >> >> On 28-Jan-2014, at 7:46 am, Marcus Sorensen >> <shadow...@gmail.com<mailto:shadow...@gmail.com>> wrote: >> >> Its an easy fix on the KVM side, just waiting to hear any objections. >> On Jan 27, 2014 6:11 PM, "Nux!" <n...@li.nux.ro<mailto:n...@li.nux.ro>> >> wrote: >> >> On 28.01.2014 00:49, Marcus Sorensen wrote: >> >> So... I tried to use memory overcommit on KVM this week, and it blew >> up in my face. Apparently it's configured such that if I have a >> Service Offering of 4G, and I set memory overprovisioning to 2:1, the >> guest only actually gets configured with 2G. That's not how >> overprovisioning is supposed to work, IMO. >> >> Here's a vm definition with a 3:1 mem overprovision setting, which >> ensures that system vms don't work: >> >> <memory unit='KiB'>262144</memory> >> <currentMemory unit='KiB'>87040</currentMemory> >> >> Note currentMemory needs to be manually tuned if I ever want the vm to >> use/see more. This is more for live scaling (which is also broken >> because the guest could just rmmod virtio-balloon and see everything). >> >> I'd like to just rip out the code that is setting ballooning feature >> based on overprovisioning factor, but perhaps there was a reason this >> was done. From my point of view, if I give someone a service offering >> that says 4G, it should provide 4G, and if I can do memory >> deduplication on the backend to overprovision that's up to me to do. >> Overprovisioning should not be a divider on all service offerings. >> >> >> Wow! I also thought, heck, KSM & thin qcows for the win! If >> overprovisioning really "works" as you described then it can't possibly be >> used for any commercial offering ... >> This needs to get fixed.. Too late to see this in 4.3? >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro<http://www.nux.ro> >> >> >>
