From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: KSM For All Via LD_PRELOAD? Date: Thu, 10 Jun 2010 10:33:13 +0300 Message-ID: <4C109539.1070401@redhat.com> References: <4C0E8F3B.5060501@bobich.net> <4C0F51C8.70802@redhat.com> <4C0F5746.5050201@redhat.com> <4C0F6D8A.5080305@bobich.net> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Gordan Bobic Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44934 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755970Ab0FJHbs (ORCPT ); Thu, 10 Jun 2010 03:31:48 -0400 In-Reply-To: <4C0F6D8A.5080305@bobich.net> Sender: kvm-owner@vger.kernel.org List-ID: 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html