From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NkOKH-0005cE-Mv for qemu-devel@nongnu.org; Wed, 24 Feb 2010 15:59:21 -0500 Received: from [199.232.76.173] (port=60882 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NkOKG-0005bv-FP for qemu-devel@nongnu.org; Wed, 24 Feb 2010 15:59:20 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NkOKF-0003FT-Kg for qemu-devel@nongnu.org; Wed, 24 Feb 2010 15:59:20 -0500 Received: from mail-pv0-f173.google.com ([74.125.83.173]:57113) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NkOKF-0003FN-4J for qemu-devel@nongnu.org; Wed, 24 Feb 2010 15:59:19 -0500 Received: by pvg13 with SMTP id 13so946931pvg.4 for ; Wed, 24 Feb 2010 12:59:17 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1267038612-21581-1-git-send-email-aliguori@us.ibm.com> References: <1267038612-21581-1-git-send-email-aliguori@us.ibm.com> Date: Wed, 24 Feb 2010 22:59:16 +0200 Message-ID: Subject: Re: [Qemu-devel] [PATCH] pc: madvise(MADV_DONTNEED) memory on reset From: Blue Swirl Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org 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.