From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gordan Bobic Subject: Re: KSM For All Via LD_PRELOAD? Date: Thu, 10 Jun 2010 10:03:16 +0100 Message-ID: <4C10AA54.2010509@bobich.net> References: <4C0E8F3B.5060501@bobich.net> <4C0F51C8.70802@redhat.com> <4C0F5746.5050201@redhat.com> <4C0F6D8A.5080305@bobich.net> <4C109539.1070401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from 78-86-195-86.zone2.bethere.co.uk ([78.86.195.86]:36328 "EHLO sentinel1.shatteredsilicon.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752931Ab0FJJDY (ORCPT ); Thu, 10 Jun 2010 05:03:24 -0400 Received: from thinkpad.shatteredsilicon.net (unknown [10.255.20.6]) by sentinel1.shatteredsilicon.net (Postfix) with ESMTP id AF6B21D8F01 for ; Thu, 10 Jun 2010 10:03:21 +0100 (BST) In-Reply-To: <4C109539.1070401@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/10/2010 08:33 AM, Dor Laor wrote: > 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. Why does it matter that the non-guest RAM areas are minimal? The way I envisage using is is by putting: export LD_PRELOAD=myksmintercept.so as the first line in rc.sysinit and having _all_ processes in the system subject to this. So the memory areas not subject to KSM would be as negligible as in the virt case if not more so. Or am I misunderstanding what you're saying? Gordan