From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NkPMy-0003gq-7o for qemu-devel@nongnu.org; Wed, 24 Feb 2010 17:06:12 -0500 Received: from [199.232.76.173] (port=38832 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NkPMx-0003gi-Ri for qemu-devel@nongnu.org; Wed, 24 Feb 2010 17:06:11 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NkPMw-0006RC-Az for qemu-devel@nongnu.org; Wed, 24 Feb 2010 17:06:11 -0500 Received: from mail-yw0-f197.google.com ([209.85.211.197]:41310) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NkPMw-0006R7-3T for qemu-devel@nongnu.org; Wed, 24 Feb 2010 17:06:10 -0500 Received: by ywh35 with SMTP id 35so2860798ywh.4 for ; Wed, 24 Feb 2010 14:06:09 -0800 (PST) Message-ID: <4B85A2C7.6040406@codemonkey.ws> Date: Wed, 24 Feb 2010 16:05:59 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] pc: madvise(MADV_DONTNEED) memory on reset References: <1267038612-21581-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org On 02/24/2010 02:59 PM, Blue Swirl wrote: > On 2/24/10, Anthony Liguori wrote: > >> If you compare the RSS of a freshly booted guest and the same guest after a >> reboot, it's very likely the freshly booted guest will have an RSS that is >> much lower the the rebooted guest because the previous run of the guest faulted >> in all available memory. >> >> This patch addresses this issue by using madvise() during reset. It only >> resets RAM areas which means it has to be done in the machine. I've only done >> this for the x86 target because I'm fairly confident that this is allowed >> architecturally on x86 although I'm not sure this is universely true. >> >> This does not appear to have an observable cost with a large memory guest and >> I can't really think of any down sides. >> > I think it would be much cleaner to make the madvise() calls from > exec.c, now you are duplicating some of the functionality there. The > calls could be controlled by a global variable (set only in pc.c) so > non-PC architectures would not be disturbed. > One thing we could do (that I think has other uses) is to add a context parameter to qemu_ram_alloc(). We could start with a simple flag of something like QRAM_RAM and QRAM_ROM. QRAM_RAM would get automatically madvise()'d on reset. But that said, does anyone know of an architecture where this type of reset would be a problem? Would it be a problem on sparc? Regards, Anthony Liguori