On Fri, Mar 12, 2010 at 02:42:59PM -0800, Kyle Bader wrote: > Vhashify is only for disk, you do need KSM for memory. this is simply wrong. given that your guests use the same distro, they will also use identical binaries and libraries, which in turn will result in unification (via vhashify) and thus in a single inode representing identical binaries and libraries for the memory this means: - single inode cache entry - single buffer cache entry - single page mapping for read only pages note that this can be a significant reduction of memory usage for a large number of 'almost' identical guests > Keep in mind that KSM has a noticeable impact on the cpu > (at least in my > environment and testing). also note that KSM requires userspace support and thus processes explicitely activating the KSM feature, which is not very likely in default userspace (distro) binaries, so I'd expect the gain from KSM to be neglectible best, Herbert > On 3/12/10, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote: > > On Fri, 2010-03-12 at 18:10 +0100, Eugen Leitl wrote: > >> This just to say that I'm highly impressed with vserver's small > >> footprint. I've tried running hundreds of vserver guests > >> on low-end hardware (4-8 GByte RAM, single/dual-core Opteron) > >> with just ssh and nginx in them, and see no issues so far, > >> even without vhashify to minimize the on-disk and in-memory > >> footprint. > >> > >> Kudos to the developers. thanks! > > I've also been very impressed and recommend the project wherever I go. > > However, does vhashify reduce the in-memory footprint or do we need to > > wait for KSM to do that? Thanks - John > > > > > > -- > Sent from my mobile device > > > Kyle