13
$\begingroup$

Some hypervisors optimize memory usage using a method that is called ballooning (at least that's what KVM calls it), this method deduplicates memory between VMs and sets common pages to read-only with copy on write.
This is sort of the opposite of a fork call.

Is it feasible to implement on an OS level for processes (I was mainly thinking of for the duplication of memory when browsing with Chromium with multiple tabs on the same site), has it been implemented already?

$\endgroup$

migrated from operatingsystems.stackexchange.com Sep 11 '14 at 12:39

14
$\begingroup$

Actually, what you've described confuses ballooning and 'same-page-merging'. I'll try to elaborate on the two to make the distinction apparent.

Memory ballooning

This is a trick to make sure that some of the memory allocated to the guest virtual machine remains usable by another guest or the host itself (caches, etc). It's done in the following way:

The guest kernel is injected with a driver, that monitors guest memory usage, and 'steals' some of the unused memory (allocating it for itself in the guest memory space, thus making sure nothing on this guest can touch that range).

Then it informs the host kernel, that it can in fact remove these memory pages from the core, that they are not going to be used in the guest (until the guest experiences some memory pressure, at which point the balloon will deflate, and use these ranges again).

Ultimately, the kernel can allocate the exact same memory to another guest, and make the entire memory usage a lot more efficient if the guests are running with a lot of free memory.

Same Page Merging

This technique identifies identical memory pages, that for some reason are not already marked 'quasi-read-only' with copy-on-write, and marks them as such.

Now, on the OS level, there is limited need for these kinds of tricks. Simply enough, most time when you have identical memory pages, they are already read-only (sometimes even without CoW), since these are mostly applications code, libraries etc. They are natively opened through a Memory Map, and thus the kernel can keep only one copy of them in core (if any at all, it can also completely page it out, and allow it to be paged in from primary store as needed).

On the virtualized OS level, the same principle is properly applied within each guest subsystem. However, the host kernel, has no idea if two of the guests are running mostly the same code, and thus are sharing the same memory - the guests don't communicate to coordinate that.

Which is why it can occasionally scan the entire system for identical memory pages - most of the time, they will be identical across the guest OS's, not within each one - the guest kernel makes a decent job keeping the memory neat within it's range. Thus, in the typical VM environment, where one host kernel handles 50+ guests, the memory savings can be pretty substantial.

Both at once

Ballooning and Same-Page-Merging can co-exist very well, achieving pretty substantial memory overcommit for identical systems.


To answer your question - the Same-Page-Merging can and sometimes is enabled at an OS level. It has to do with page sharing that are interpreted, and thus could end up being identical without having the same backing file.

In your Chromium example - the process binaries themselves are already deduplicated through read-only startup map - they share the exact same memory space. The page caches (contents of the tabs) are usually also shared between processes (read-only copy-on-write) due to the way disk cache is managed - the same on-disk file can be opened simulatenously between different processes in the VM-optimal sense.

The advantage would be most evident with the shared state of different Javascript engines - but I'm not sure if they are allocated in the exact same memory layout, ensuring that the entire memory page is identical.

This is different on mobile systems. Android, for instance, extensively employs KSM to deduplicate identical code between different applications.

In either case, you can enable it yourself on Linux (Kernel SamePage Merging). The driver exports various statistics that, after reading this answer, you should be able to interpret, and make your own decision whether it's a good match for your purpose.

https://www.kernel.org/doc/Documentation/vm/ksm.txt

$\endgroup$
  • 3
    $\begingroup$ Same-page merging is also referred to as 'transcendent memory', depending on the hypervisor (and age of it). $\endgroup$ – Tim Post Aug 25 '14 at 12:20
  • $\begingroup$ Thank you, I see that KSM requires the application to be aware of it, and from a (quick) search, Chromium does not support it as of now. I am aware that the binaries are deduplicated, but I'm mostly referring to the JIT output and the raw scripts that put a heavy strain on my RAM... $\endgroup$ – David Kohen Aug 25 '14 at 15:46
  • $\begingroup$ Raw scripts in Chromium are also deduplicated - they land in disk cache as with all the other web objects, and disk cache is mapped, not read. $\endgroup$ – qdot Aug 25 '14 at 19:58
  • $\begingroup$ The raw scripts are mapped, but even common scripts (like jQuery and Angular.js) are replicated in the cache and they are not matched with one another since there's heavy use of CDNs and exact replicas of script files on the various site servers. $\endgroup$ – David Kohen Aug 26 '14 at 10:37
  • $\begingroup$ This probably should end up in chat, but I'd love to see your statistics from Linux's KSM. $\endgroup$ – qdot Aug 26 '14 at 11:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.