On 06/09/2010 01:31 PM, Gordan Bobic wrote:
On 06/09/2010 09:56 AM, Paolo Bonzini wrote:
Or is this too crazy an idea?
It should work. Note that the the malloced memory should be aligned in
order to get better sharing.
Within glibc malloc large blocks are mmaped, so they are automatically
aligned. Effective sharing of small blocks would take too much luck or
too much wasted memory, so probably madvising brk memory is not too
useful.
Of course there are exceptions. Bitmaps are very much sharable, but not
big. And some programs have their own allocator, using mmap in all
likelihood and slicing the resulting block. Typically these will be
virtual machines for garbage collected languages (but also GCC for
example does this). They will store a lot of pointers in there too, so
in this case KSM would likely work a lot for little benefit.
So if you really want to apply it to _all_ processes, it comes to mind
to wrap both mmap and malloc so that you can set a flag only for
mmap-within-malloc... It will take some experimentation and heuristics
to actually not degrade performance (and of course it will depend on the
workload), but it should work.
Arguably, the way QEMU KVM does it for the VM's entire memory block
doesn't seem to be distinguishing the types of memory allocation inside
the VM, so simply covering all mmap()/brk() calls would probably do no
worse in terms of performance. Or am I missing something?
There won't be drastic effect for qemu-kvm since the non guest ram areas
are minimal. I thought you were trying to trap mmap/brk/malloc for other
general applications regardless of virt.
Gordan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
