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=-5.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 2BAEBC33CA1 for ; Wed, 5 Feb 2020 10:27:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D32DC2082E for ; Wed, 5 Feb 2020 10:27:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="C9SQWzT6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D32DC2082E 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 7DC616B00AC; Wed, 5 Feb 2020 05:27:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78C5C6B00AD; Wed, 5 Feb 2020 05:27:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67C976B00AE; Wed, 5 Feb 2020 05:27:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id 4A35B6B00AC for ; Wed, 5 Feb 2020 05:27:55 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D8AE41EF3 for ; Wed, 5 Feb 2020 10:27:54 +0000 (UTC) X-FDA: 76455697668.10.mass07_450a85222031d X-HE-Tag: mass07_450a85222031d X-Filterd-Recvd-Size: 9144 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Wed, 5 Feb 2020 10:27:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580898473; 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=33mopyn99J3hszGu+c7kCbx0/fFDH1XzgIPig+rayyg=; b=C9SQWzT6uLg1MAOGrNdOulBeRaeRI977KBDdU+mmCWDHOXdi6xvzb0CXQ6X8GvcDys2LEN lbqpDNERlvQi7k2CsgmR0VZUuRtyBKX3J9OHvzZmwiQIMQHVOPaYxGP04Mee99xNd3E/CE 7L6mRBBZyJlFf7s9tARzpcBK80KZKOg= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-194-NclFlJ9DMkCOGbGS2NIl9A-1; Wed, 05 Feb 2020 05:27:50 -0500 Received: by mail-qk1-f198.google.com with SMTP id y6so947298qki.13 for ; Wed, 05 Feb 2020 02:27:50 -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:content-transfer-encoding :in-reply-to; bh=cW1b82F1PITWykLK+hGaf47Vke07eMy3FQk2TjUggGs=; b=EJQBI6L3qqVgHz9KAqb8d7vdijIAzN++cqEWPO8FRxJArZP34CjWEoyGgvtDK49teT Ft4Wy0P/OngQa2gB+T6x5JyGeLFzRAp9K37JQf3hdokbwOums5oW+QgzP6+dfZ7+hP1x tz9F7+DteYS0tzbV7BmqJJXO3zBnDFc89Kxf6Gn0sBSV+lvjBciQqYzfpMuTHCryM9hR xOlVWvcYmf1qb4uCFpDPNXVd3XCaBE6oA/KudAkcMSpA3m1tvoFa9GTIXj+UQO3Uag8a Uhy2VzhC6Ng3TEKi9b6tdd/urimLaEoSc6Tcyi9KZgc6xhV2siTNn2PBb0Sa31eLlHq0 Oe6g== X-Gm-Message-State: APjAAAWB9m7LmSD3BgqM7eLOzNwqitBQFvec8NXaTiHI2qjjbOvGhcdg mcPuicb1hdtUJWSInwXGB3SaPW8gYKFrkb4gW1lc5V/VZDAKoz5H/eE/kPffqBoiADujeIbsHeF myb5QpcBqJ3w= X-Received: by 2002:ac8:7b29:: with SMTP id l9mr31716912qtu.141.1580898469592; Wed, 05 Feb 2020 02:27:49 -0800 (PST) X-Google-Smtp-Source: APXvYqyqWPcxZs+M6fAFj2LtT+PEHBGg6JTnya60dAPCPVdp/LYRW/TIc9Q3mttRYgjIOa+1coF9ow== X-Received: by 2002:ac8:7b29:: with SMTP id l9mr31716892qtu.141.1580898469295; Wed, 05 Feb 2020 02:27:49 -0800 (PST) Received: from redhat.com (bzq-79-176-41-183.red.bezeqint.net. [79.176.41.183]) by smtp.gmail.com with ESMTPSA id y26sm12965707qtv.28.2020.02.05.02.27.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Feb 2020 02:27:48 -0800 (PST) Date: Wed, 5 Feb 2020 05:27:44 -0500 From: "Michael S. Tsirkin" To: David Hildenbrand Cc: Nadav Amit , Alexander Duyck , Tyler Sanderson , "Wang, Wei W" , "virtualization@lists.linux-foundation.org" , David Rientjes , "linux-mm@kvack.org" , Michal Hocko Subject: Re: Balloon pressuring page cache Message-ID: <20200205052548-mutt-send-email-mst@kernel.org> References: <75d4594f-0864-5172-a0f8-f97affedb366@redhat.com> <286AC319A985734F985F78AFA26841F73E3F8A02@shsmsx102.ccr.corp.intel.com> <20200203080520-mutt-send-email-mst@kernel.org> <5ac131de8e3b7fc1fafd05a61feb5f6889aeb917.camel@linux.intel.com> <539B606A-A0CA-4AA4-B99A-759C874A1EF8@vmware.com> <08D323B9-0B4A-47B2-9955-511B8FBA056B@vmware.com> MIME-Version: 1.0 In-Reply-To: X-MC-Unique: NclFlJ9DMkCOGbGS2NIl9A-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 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 Wed, Feb 05, 2020 at 09:19:58AM +0100, David Hildenbrand wrote: > On 05.02.20 08:35, Nadav Amit wrote: > >> On Feb 3, 2020, at 2:50 PM, Nadav Amit wrote: > >> > >>> On Feb 3, 2020, at 8:34 AM, David Hildenbrand wrot= e: > >>> > >>> On 03.02.20 17:18, Alexander Duyck wrote: > >>>> On Mon, 2020-02-03 at 08:11 -0500, Michael S. Tsirkin wrote: > >>>>> On Thu, Jan 30, 2020 at 11:59:46AM -0800, Tyler Sanderson wrote: > >>>>>> On Thu, Jan 30, 2020 at 7:31 AM Wang, Wei W = wrote: > >>>>>> > >>>>>> On Thursday, January 30, 2020 11:03 PM, David Hildenbrand wrote: > >>>>>>> On 29.01.20 20:11, Tyler Sanderson wrote: > >>>>>>>> On Wed, Jan 29, 2020 at 2:31 AM David Hildenbrand >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>> On 29.01.20 01:22, Tyler Sanderson via Virtualization wrote: > >>>>>>>>> A primary advantage of virtio balloon over other memory reclaim > >>>>>>>>> mechanisms is that it can pressure the guest's page cache into > >>>>>>>> shrinking. > >>>>>>>>> However, since the balloon driver changed to using the shrinker > >>>>>> API > >>>>>>> >>>>>>> e99a28e355255a#diff-fd202acf694d9eba19c8c64da3e480c9> this > >>>>>>>>> use case has become a bit more tricky. I'm wondering what the > >>>>>>> intended > >>>>>>>>> device implementation is. > >>>>>>>>> > >>>>>>>>> When inflating the balloon against page cache (i.e. no free > >>>>>> memory > >>>>>>>>> remains) vmscan.c will both shrink page cache, but also invoke > >>>>>> the > >>>>>>>>> shrinkers -- including the balloon's shrinker. So the balloon > >>>>>> driver > >>>>>>>>> allocates memory which requires reclaim, vmscan gets this memor= y > >>>>>>> by > >>>>>>>>> shrinking the balloon, and then the driver adds the memory back > >>>>>> to > >>>>>>> the > >>>>>>>>> balloon. Basically a busy no-op. > >>>>>> > >>>>>> Per my understanding, the balloon allocation won=E2=80=99t invok= e shrinker as > >>>>>> __GFP_DIRECT_RECLAIM isn't set, no? > >>>>>> > >>>>>> I could be wrong about the mechanism, but the device sees lots of = activity on > >>>>>> the deflate queue. The balloon is being shrunk. And this only star= ts once all > >>>>>> free memory is depleted and we're inflating into page cache. > >>>>> > >>>>> So given this looks like a regression, maybe we should revert the > >>>>> patch in question 71994620bb25 ("virtio_balloon: replace oom notifi= er with shrinker") > >>>>> Besides, with VIRTIO_BALLOON_F_FREE_PAGE_HINT > >>>>> shrinker also ignores VIRTIO_BALLOON_F_MUST_TELL_HOST which isn't n= ice > >>>>> at all. > >>>>> > >>>>> So it looks like all this rework introduced more issues than it > >>>>> addressed ... > >>>>> > >>>>> I also CC Alex Duyck for an opinion on this. > >>>>> Alex, what do you use to put pressure on page cache? > >>>> > >>>> I would say reverting probably makes sense. I'm not sure there is mu= ch > >>>> value to having a shrinker running deflation when you are actively t= rying > >>>> to increase the balloon. It would make more sense to wait until you = are > >>>> actually about to start hitting oom. > >>> > >>> I think the shrinker makes sense for free page hinting feature > >>> (everything on free_page_list). > >>> > >>> So instead of only reverting, I think we should split it up and alway= s > >>> register the shrinker for VIRTIO_BALLOON_F_FREE_PAGE_HINT and the OOM > >>> notifier (as before) for VIRTIO_BALLOON_F_MUST_TELL_HOST. > >>> > >>> (Of course, adapting what is being done in the shrinker and in the OO= M > >>> notifier) > >> > >> David, > >> > >> Please keep me posted. I decided to adapt the same solution as the vir= tio > >> balloon for the VMware balloon. If the verdict is that this is damagin= g and > >> the OOM notifier should be used instead, I will submit patches to move= to > >> OOM notifier as well. > >=20 > > Adding some information for the record (if someone googles this thread)= : > >=20 > > In the VMware balloon driver, the shrinker is disabled by default since= we > > encountered a performance degradation in testing. I tried to avoid rapi= d > > inflation/shrinker-deflation cycles by adding a timeout, but apparently= it > > did not help in avoiding the performance regression. >=20 > Thanks for that info. To me that sounds like the shrinker is the wrong > approach to "auto-deflation". It's not just "some slab cache". So as you pointed out yourself deflate on oom is really under-specified. I would be very happy if you could take a stub at documenting what's expected from guest and how it could be used. Please copy the virtio TC when you do this as this is spec stuff. >=20 > --=20 > Thanks, >=20 > David / dhildenb