From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CBEFC2BA83 for ; Sun, 16 Feb 2020 09:47:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EFCC820857 for ; Sun, 16 Feb 2020 09:47:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DmiWIFzG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFCC820857 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A411C6B0008; Sun, 16 Feb 2020 04:47:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F0A86B000A; Sun, 16 Feb 2020 04:47:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DFE16B000C; Sun, 16 Feb 2020 04:47:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 780D86B0008 for ; Sun, 16 Feb 2020 04:47:22 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 17E374DB3 for ; Sun, 16 Feb 2020 09:47:22 +0000 (UTC) X-FDA: 76495512324.30.eye87_403aa9a97db56 X-HE-Tag: eye87_403aa9a97db56 X-Filterd-Recvd-Size: 7069 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Sun, 16 Feb 2020 09:47:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581846440; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q23cP3TKmnOYXWHTxWi4lm/dNa5/+S4j5MZht74Fi2g=; b=DmiWIFzGi+Z6zjnK//k1kj0pnKVwhHy7xfPIX5gxveVvnbAupGpdd+Wb2wmwmzlG9FiVJ5 xSIzDaO1LoRJfeqHulJ+iQIiV2+JP+xb//pktmk6hsO3V6i257ggsUsBXBajzbdTS+lVEy caoKzFPLHQmuAoAdh1/Kq3tGbVQR2Js= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-397-Lgld3POVP_W4CUvhknVEMQ-1; Sun, 16 Feb 2020 04:47:17 -0500 Received: by mail-wm1-f70.google.com with SMTP id f207so5948254wme.6 for ; Sun, 16 Feb 2020 01:47:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3c/WN0m/fSra0TkxvPfDqbPdSXCm+vdA6iOX3UjbCRY=; b=BlNHBI1ZUixm0wMBPpY5BbxrmOtLrK/nBcOE++qz7OagDte9GBsdeaeOPN7Rvj4/w1 wIADlJLrnO/e6rohKB/iAYgAj/0haUL8l9MeOPDl5Mj2izfXqj//Ve5hDdRstYay5qkH 1aF85Rc2naULt7PEwGhgdWZTY+to7G6cLeKaNBlXmZasuKW4DcbnbugW+EdP7g1wyq+m +eAlYWYST8fkWR/rF7AMR+PEGCNRx21f51o6ePD58po/sjJ93RBETnDakXIuXcbponcF sZ3sAZPThYvWRjlhUCGcdGv4mJ69TPvm4QkobTtRnRpdpCNsiISu42osErX10esxdByl oU+Q== X-Gm-Message-State: APjAAAXf52ZhYF67T4GhFAA9k4Qa/A2T6R8aMlrhMvG9NlYE1J1mQsl0 jRJX6ayzkt6diwLJQ7kiorOP/Z1YYVL2XgejM8k00eABT6vuPFJmsJF38tYHKBjz8P3vluvZXsC hgDc8hZ8uh0s= X-Received: by 2002:adf:81c2:: with SMTP id 60mr14899135wra.8.1581846435983; Sun, 16 Feb 2020 01:47:15 -0800 (PST) X-Google-Smtp-Source: APXvYqzG6RrsUSe8N2Fvm+d5duF0MuB1svG4/FyfcHkv6fRCRbqtrjKVH9j/IKcsdYDYK8VCFBolkQ== X-Received: by 2002:adf:81c2:: with SMTP id 60mr14899111wra.8.1581846435739; Sun, 16 Feb 2020 01:47:15 -0800 (PST) Received: from redhat.com (bzq-79-176-28-95.red.bezeqint.net. [79.176.28.95]) by smtp.gmail.com with ESMTPSA id a16sm14989900wrx.87.2020.02.16.01.47.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Feb 2020 01:47:15 -0800 (PST) Date: Sun, 16 Feb 2020 04:47:12 -0500 From: "Michael S. Tsirkin" To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, virtualization@lists.linux-foundation.org, Tyler Sanderson , Wei Wang , Alexander Duyck , David Rientjes , Nadav Amit , Michal Hocko Subject: Re: [PATCH v1 3/3] virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM Message-ID: <20200216044641-mutt-send-email-mst@kernel.org> References: <20200205163402.42627-1-david@redhat.com> <20200205163402.42627-4-david@redhat.com> MIME-Version: 1.0 In-Reply-To: X-MC-Unique: Lgld3POVP_W4CUvhknVEMQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 14, 2020 at 10:51:43AM +0100, David Hildenbrand wrote: > On 05.02.20 17:34, David Hildenbrand wrote: > > Commit 71994620bb25 ("virtio_balloon: replace oom notifier with shrinke= r") > > changed the behavior when deflation happens automatically. Instead of > > deflating when called by the OOM handler, the shrinker is used. > >=20 > > However, the balloon is not simply some slab cache that should be > > shrunk when under memory pressure. The shrinker does not have a concept= of > > priorities, so this behavior cannot be configured. > >=20 > > There was a report that this results in undesired side effects when > > inflating the balloon to shrink the page cache. [1] > > =09"When inflating the balloon against page cache (i.e. no free memory > > =09 remains) vmscan.c will both shrink page cache, but also invoke the > > =09 shrinkers -- including the balloon's shrinker. So the balloon > > =09 driver allocates memory which requires reclaim, vmscan gets this > > =09 memory by shrinking the balloon, and then the driver adds the > > =09 memory back to the balloon. Basically a busy no-op." > >=20 > > The name "deflate on OOM" makes it pretty clear when deflation should > > happen - after other approaches to reclaim memory failed, not while > > reclaiming. This allows to minimize the footprint of a guest - memory > > will only be taken out of the balloon when really needed. > >=20 > > Especially, a drop_slab() will result in the whole balloon getting > > deflated - undesired. While handling it via the OOM handler might not b= e > > perfect, it keeps existing behavior. If we want a different behavior, t= hen > > we need a new feature bit and document it properly (although, there sho= uld > > be a clear use case and the intended effects should be well described). > >=20 > > Keep using the shrinker for VIRTIO_BALLOON_F_FREE_PAGE_HINT, because > > this has no such side effects. Always register the shrinker with > > VIRTIO_BALLOON_F_FREE_PAGE_HINT now. We are always allowed to reuse fre= e > > pages that are still to be processed by the guest. The hypervisor takes > > care of identifying and resolving possible races between processing a > > hinting request and the guest reusing a page. > >=20 > > In contrast to pre commit 71994620bb25 ("virtio_balloon: replace oom > > notifier with shrinker"), don't add a moodule parameter to configure th= e > > number of pages to deflate on OOM. Can be re-added if really needed. > > Also, pay attention that leak_balloon() returns the number of 4k pages = - > > convert it properly in virtio_balloon_oom_notify(). > >=20 > > Note1: using the OOM handler is frowned upon, but it really is what we > > need for this feature. > >=20 > > Note2: without VIRTIO_BALLOON_F_MUST_TELL_HOST (iow, always with QEMU) = we > > could actually skip sending deflation requests to our hypervisor= , > > making the OOM path *very* simple. Besically freeing pages and > > updating the balloon. If the communication with the host ever > > becomes a problem on this call path. > >=20 >=20 > @Michael, how to proceed with this? >=20 I'd like to see some reports that this helps people. e.g. a tested-by tag. > --=20 > Thanks, >=20 > David / dhildenb