Anatomy of Linux Kernel Shared Memory 93
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.
Re:First Post (Score:5, Insightful)
If your OS isn't sharing duplicate memory blocks already, you're using a shitty OS. (Linux already shares dup read only blocks for many things, like most modern OSes).
Umm, no.
Most modern OSes share memory for executable images and shared libraries. In addition, some OSes, such as Linux, support copy-on-write semantics for memory pages in child processes created with fork (note, Solaris is an example of an OS that *doesn't* do this).
Aside from that, there is no automated sharing of memory between processes. Frankly, I have no idea where you got the idea there was.
Re:This Is Just One Reason ... (Score:3, Insightful)
far better documentation from MS and Apple than Linux has ever had.
Have you ever looked at Amazon or InformIT/Safari or any technical documentation vendor or website? There are enough books and articles on MS and Linux to keep you reading for many lifetimes (Apple not so much, but still plenty by my estimate). It's just a FACT that there are certain things that closed source vendors do not disclose as a matter of trade secret or intellectual property, which is what I believe WrongSizeGlass was referring to. OSS does not have this limitation.
And no, the source doesn't count if no one knows what you intended to do
It absolutely does count, if you know how to read code. You can read documentation all day long, but if it doesn't match the code you'll be lost.
When I get involved in a rewrite/upgrade/modification of an existing application (and I've worked on many much larger than most OSS apps, and I've been doing it for over 30 years - so it think I have a clue), I read the docs for a quick overview, but I read the code to find out how it really works.
I've spent plenty of time with both msdn.microsoft.com (and developer.apple.com to a lesser degree) over the years and while there are loads of information there, I know "everything" is not there. There are API documentation discrepancies, quirks, or various undocumented oddities that can be frustrating to work around. These issues can only be resolved one of two ways - trial and error or by reading the code.
With closed source there is only one way - pray the docs are correct. With open source there are usually two ways and if the documentation is shitty, you can be sure the code is correct. That makes my life as a developer easier.
Get a clue fanboy.
Wow. I'm sure you won him over with that jab. First an outpouring of pomposity and narcissism, then a put-down to finish it off.
Good job dude.
Re:First Post (Score:3, Insightful)
This article [sun.com] claims that on Solaris, "fork() has been improved over the years to use the COW (copy-on-write) semantics". It's sort of an in-passing comment, though, and I can't find a definitive statement in docs anywhere (the Solaris fork() manpage [sun.com] doesn't give any details).
Re:This Is Just One Reason ... (Score:3, Insightful)
Take it from a guy who's seen the NT source code: Inside Windows 2000, the windows kernel debuggers, and a firewire cable gave you MORE than enough detail; there's not much important that's not publicly known.
It just doesn't make Slashdot or the sites you frequent. How do you think Windows Device Driver writers do their job?
Re:This Is Just One Reason ... (Score:2, Insightful)
How do you think Windows Device Driver writers do their job?
Very badly if my experience is anything to go on.
Good on them. (Score:1, Insightful)
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.
Re:First Post (Score:5, Insightful)
Aside from all the places that memory is shared between processes, theres no sharing between processes ... yea, I totally get you ...
That's exactly right. I pointed out all the places. *All of them*. And there's *two*: shared, read-only executable pages, and the heaps of children created by COW-enabled forks. That's it. That's all.
So any new technology for memory de-duping is impressive because, traditionally, it just ain't done. Which directly contradicts the content of your original post.
Perhaps now you understand?