| |||||||||||||
Memory deduplication by common disk sourceMemory deduplication by common disk sourcePosted May 3, 2009 2:47 UTC (Sun) by giraffedata (subscriber, #1954)In reply to: Close but no cigar by khim Parent article: KSM tries again
Your point about KSM working in the here and now is good, but as a question of long term strategy, ncm's is equally good. Maybe KSM should be thought of as a stop-gap. In the systems where the memory duplication is a big problem, the common disk source of the memory pages is a lot closer than Debian's build server. If you have a hundred virtual machines, you probably did the Debian install once and copied the disk image a hundred times locally. If that copy is a naive physical copy, then it's still hard for the hypervisor to know that two memory pages have the same ultimate source. But if you apply the same deduplication strategy to the duplicated disk (and there's plenty of work going on to make that a reality), then you have 100 virtual disk devices all sharing the same physical disk blocks and the hypervisor knows it. So it can easily back 100 virtual memory pages with a single real memory page.
(Log in to post comments)
Memory deduplication by common disk source Posted Nov 22, 2009 21:26 UTC (Sun) by kabloom (guest, #59417) [Link]
There's another situation where this is useful: interpreted languages. Supposing you run a rails app on your server. To take advantage of concurrency you fork the rails app several times. All of the Rails code (parsed already, and byte-compiled if you're on Ruby 1.9) is on Copy-on-write pages. (Ruby Enterprise Edition is intended to keep the garbage collector from writing to those pages.) Now suppose you run several apps but they don't come about by forking. The Rails code (parsed or byte-compiled) can't be traced back to a single disk block (because it's been parsed) but it's probably got the same page layout despite being loaded in different interpreters. Here, KSM should help.
|
|||||||||||||