Anatomy of Linux Kernel Shared Memory
An anonymous reader sends in an IBM DeveloperWorks backgrounder on Kernel Shared Memory in the 2.6.32 Linux kernel. KSM allows the hypervisor to increase the number of concurrent virtual machines by consolidating identical memory pages. The article covers the ideas behind KSM (such as storage de-duplication), its implementation, and how you manage it.
Seems to me this feature has been available for a while in VMWare...
they are so informative now that the KernelTrap isn't updating regularly ... AHEM! *cough! *cough! there is some reorganization of linux graphics and networking that needs to be updated. (or has linux networking changed sense 2005
... why OSS is the way things should be. You'll never see this type of documentation, and this type of detail, available to anyone and everyone from closed source software. I love my Mac, and supporting Windows pays my bills, but OSS is unlike any other animal out there.
sense when did IBM care so much about Linux?
That's so lame. It's 2010, why use Windows 2008?
Ezekiel 23:20
There are signs of life at KernelTrap (http://kerneltrap.org/).
There have been a number of postings by Jeremy since the beginning of April.
I start daemons myself, you insensitive clod!
Dilbert RSS feed
If you are running 10 processes on 10 servers on one physical machine... isn't easier and more efficient to run 100 processes on one instance of Linux?
Kernel shared memory only acts on memory pages which it has been advised could be duplicates. This requires applications to specifically tag pages of memory as possibly being duplicates.
Useful for virtualization (which is the primary purpose), but probably not actually functionally useful for more general memory de-duplication.
This could be one of the worst ideas ever ... thats all i can say ...
if you need more info ask everyone else !
The use of KSM isn't without risk:
"A region can be removed from the mergeable state through the MADV_UNMERGEABLE parameter (which immediately un-merges any merged pages from that region). Note that removing a region of pages through madvise can result in an EAGAIN error, as the operation could run out of memory during the un-merge process, potentially leading to even greater trouble (out-of-memory conditions). "
KSM *will* overcommit the memory as it is designed to do so. And please also be mindful that Murphy's Law always tends to hit when you least suspect it.
Muchas Gracias, Señor Edward Snowden !
First off, as several people have said, IBM did VM over 40 years ago, hypervisors, full hardware virtualization, virtual memory, loads of failover type stuff since they are mainframes after all. Right now the modern wave of VMs are about where IBM was back then (with perhaps failover still being perfected.) IBM mainframe CPUs run the pipeline 2x, with a comparator in between the 2 copies to make sure everything matches. After 1 fault, it backs the pipeline up one and reruns it (and I'm sure logs a fault)... second failure, the CPU is shut off and load put on a spare.
Anyway, for sure memory sharing will massively cut RAM usage in some cases... I'm thinking ISPs where they rent you out a VM, many many people will keep stock (i.e. ISP-supplied) linux kernel + mostly stock apps executing.. which is actually fairly small but could easily save at least 100s of MBs with a good number of VMs on a box.
"KSM allows the hypervisor to increase the number of concurrent virtual machines by consolidating identical memory pages."
But first you have to waterboard it.
http://www.rootstrikers.org/
.
KSM is a great idea, much of its abilities are available in Fedora 12. I tried it and I had higher expectations to be honest.
That is not to say that it is no good - its great but there is a bit of a cost analsysis that should be done before implementing it. You dont get something for nothing - and in this case ultimately your offloading the higher memory usage onto the CPU. Depending on your hypervisor setup this might not be such a bad thing of course.
In my somewhat narrow testing of it I found that:-
a) Even with the same O/S images running multiple times the memory I saved was about 5-10%.
b) It effectively used about 50% of one CPU running the feature.
I think that to really see a benefit to this you have to be running a huge hypervisor with a ton of memory and cpus and a lot of guests as there is a plateau which beforehand makes it quite inefficient to use the features seeing as (at least with my results) the payback is less than 10% anyway.
Linux has had this long ago.
http://www.complang.tuwien.ac.at/ulrich/mergemem/ - for example.
Note that the savings referred to are on kernel 2.0.33.
I used it on my 8M laptop - worked well.
No, really.
Deleted