From patchwork Thu Feb 14 04:39:12 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Gibson X-Patchwork-Id: 10811791 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6FE91746 for ; Thu, 14 Feb 2019 04:44:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5E05428796 for ; Thu, 14 Feb 2019 04:44:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 507FA28B57; Thu, 14 Feb 2019 04:44:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id EA7C828796 for ; Thu, 14 Feb 2019 04:44:10 +0000 (UTC) Received: from localhost ([127.0.0.1]:39975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gu8sc-0004AU-8a for patchwork-qemu-devel@patchwork.kernel.org; Wed, 13 Feb 2019 23:44:10 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gu8p5-0002EK-6a for qemu-devel@nongnu.org; Wed, 13 Feb 2019 23:40:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gu8on-0006up-L7 for qemu-devel@nongnu.org; Wed, 13 Feb 2019 23:40:18 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:60135) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gu8oh-0006OU-2u; Wed, 13 Feb 2019 23:40:09 -0500 Received: by ozlabs.org (Postfix, from userid 1007) id 440Nvr19PMz9sMp; Thu, 14 Feb 2019 15:39:20 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1550119160; bh=B7BjmFE145e/oytYlbFVg2OL0vdT6WxWyxJuj/WEYEU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kz/kX8al1JcrlNOYEfi81kbCw1VPJ4158vmTiNKBOfFuS5bRZLPCmzj1MUVF2eo8Z qSRtMWFMqqS30GdFlIzvQEVIkZTc4VBJ3KkVusOnkrHFVjCkqbFKGy3pqI1FAU+Tvc WnDlzvXLPKtZk1lmkl2tQ54LpBzzRiHKBykYLoNs= From: David Gibson To: mst@redhat.com, qemu-devel@nongnu.org Date: Thu, 14 Feb 2019 15:39:12 +1100 Message-Id: <20190214043916.22128-2-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190214043916.22128-1-david@gibson.dropbear.id.au> References: <20190214043916.22128-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2401:3900:2:1::2 Subject: [Qemu-devel] [PATCH 1/5] virtio-balloon: Remove unnecessary MADV_WILLNEED on deflate X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Hildenbrand , qemu-ppc@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP When the balloon is inflated, we discard memory place in it using madvise() with MADV_DONTNEED. And when we deflate it we use MADV_WILLNEED, which sounds like it makes sense but is actually unnecessary. The misleadingly named MADV_DONTNEED just discards the memory in question, it doesn't set any persistent state on it in-kernel; all that's necessary to bring the memory back is to touch it. MADV_WILLNEED in contrast specifically says that the memory will be used soon and faults it in. This patch simplify's the balloon operation by dropping the madvise() on deflate. This might have an impact on performance - it will move a delay at deflate time until that memory is actually touched, which might be more latency sensitive. However: * Memory that's being given back to the guest by deflating the balloon *might* be used soon, but it equally could just sit around in the guest's pools until needed (or even be faulted out again if the host is under memory pressure). * Usually, the timescale over which you'll be adjusting the balloon is long enough that a few extra faults after deflation aren't going to make a difference. Signed-off-by: David Gibson Reviewed-by: David Hildenbrand Reviewed-by: Michael S. Tsirkin --- hw/virtio/virtio-balloon.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c index a12677d4d5..43af521884 100644 --- a/hw/virtio/virtio-balloon.c +++ b/hw/virtio/virtio-balloon.c @@ -35,9 +35,8 @@ static void balloon_page(void *addr, int deflate) { - if (!qemu_balloon_is_inhibited()) { - qemu_madvise(addr, BALLOON_PAGE_SIZE, - deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED); + if (!qemu_balloon_is_inhibited() && !deflate) { + qemu_madvise(addr, BALLOON_PAGE_SIZE, QEMU_MADV_DONTNEED); } }