from the research department - ramster in Linux 3.4 staging drivers

Some developers on my team have spent quite a few years on doing research and development on new ways of doing memory management better across servers, both physical and virtual. You often hear me talk about cooperative memory management in the context of Oracle VM. I believe it is important to be able to do memory overcommit the right way and have both the guest OS and the hypervisor know what's going on, instead of having the hypervisor do things behind the guest's back. Transparent memory overcommit causes unpredictable behavior for applications and while this might be of little concern when consolidating lots of small VMs that aren't doing much interesting. When you have applications that are, by nature, memory intensive, such as an Oracle database or any sort of production environment, then there need to be better ways to do this. Better, here, meaning -> more efficient, more predictable and more cooperative between host and guest.

It's a long road to getting all these stars aligned but we are very close now in terms of Linux kernel features to help with this. Over the last few years Dan Magenheimer has been working hard on what's called transcendent memory, a collection of features that include cleancache, frontswap and ramster. Now with Linux 3.4, we have tmem, cleancache and ramster in kernel upstream. Frontswap is still pending but we're working on it.

As a refresher, you can read more about cleancache in this writeup I did just bout a year ago. Frontswap is more tricky, because here we can use transcendent memory as a swap device. Pages swapped out cannot just disappear, they have to be persistent until the OS decides to no longer need them. In other words, with cleancache we provide extra memory(extra cache) but with the understanding that that extra memory might just disappear. With frontswap, we provide swap space through the same mechanism, with the understanding that it's not going to just disappear. One place where frontswap is different from regular swap, is its size. A swapdevice is pre-created with a specific size, a file acting as a swap device or a physical/logical volume. They do not grow or shrink dynamically. frontswap is more dynamic. The advantage of frontswap is that you can use ram on a remote server or in the hypervisor as very fast storage. It can also do compression of memory pages using zcache.

If you want to play with ramster, Dan wrote up a simple how-to.
Dan also wrote up a presentation which you can find here.

Looking forward to frontswap getting into the kernel and many of these features get into customers hands through the Unbreakable Enterprise Kernel and as products evolve and features get management also into Oracle VM.