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 C638AC35247 for ; Tue, 4 Feb 2020 20:33:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7B0702087E for ; Tue, 4 Feb 2020 20:33:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XfVgEsDe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B0702087E 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 1BB676B0006; Tue, 4 Feb 2020 15:33:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 16C4C6B0007; Tue, 4 Feb 2020 15:33:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05B9D6B0008; Tue, 4 Feb 2020 15:33:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id E30266B0006 for ; Tue, 4 Feb 2020 15:33:31 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9F265180AD804 for ; Tue, 4 Feb 2020 20:33:31 +0000 (UTC) X-FDA: 76453595022.13.songs44_3bd597c1f0b52 X-HE-Tag: songs44_3bd597c1f0b52 X-Filterd-Recvd-Size: 7394 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Feb 2020 20:33:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580848410; 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=89moUsjakkhR5UHZDfDkAiCQhgMAGDC7bOy6XlSDyp0=; b=XfVgEsDeuTm+ALXVedMgfQM2AnUGRu/tUaPgqg0Axj7Qc9dBP75CRGqHALIoypeKhLjHsV aU09rB6M9BV88r0LESlLZzmJEQZOnV/p7Tq62f9vM3MID7c4nf1MmFoaiEj4rPVCLSyovi sfFqazBnVo/i1Eki0eHmWnKeu28ex70= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-135-zYRTd3pVM0W4xejnw9OxXw-1; Tue, 04 Feb 2020 15:33:25 -0500 Received: by mail-qt1-f197.google.com with SMTP id d9so13186932qtq.13 for ; Tue, 04 Feb 2020 12:33:25 -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=THAEQOMHoaTiiOPbX7h8DNEEb4f2RS0VVJtOdkMrYnk=; b=kxWgZd98PtKjoGTYtBlbKt18ykDsmkO1ULAuQjg9uFlQ3LGkOYESwgyucDwIEgGHTC LeLanmuPzd0veYdpgZ44VsGRoVWhRDeGROa4OYpCQHle1zggSqkLhZ3N9HsgMsVE70P8 7Jb1asPytSkeOA3pgB/JYkaVzXdHse5z/+f346HhQ6bIPrVDqNqt4UkAxRju/zYH0a0L T0WjKIvhqrHFtWXnjLa/c0ciN0Oz1YdHF5dXd+7z5Odaep8s6AwQMP9WNQ2O/D4yD5QM XVxUkS1qAlJjVklJjW61qszQJWBe91Psc8hGFDXCazWu/7Ls2tpLjPmHNfgm14PqrnEe zNZA== X-Gm-Message-State: APjAAAXFVfjmepiZAblDp80I921DvFslaopzb4LyHWx4wNT7JH40oENa 16chLCTIa05ki1mEil0xVM4OD8MBtalMnFbb61K9d4tvGs3umCUnJINwxC7PvS2HD+jNb1QboEi Pj1K11nyrJOc= X-Received: by 2002:a37:5f43:: with SMTP id t64mr29794584qkb.68.1580848404829; Tue, 04 Feb 2020 12:33:24 -0800 (PST) X-Google-Smtp-Source: APXvYqwHCJIK6lZHuMLfq4/XKFYBcuLQvXb+yE8q6jIqNW3eBTt1giB0KZigC8t93YVW1+WpypJn1A== X-Received: by 2002:a37:5f43:: with SMTP id t64mr29794566qkb.68.1580848404511; Tue, 04 Feb 2020 12:33:24 -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 21sm11604054qky.41.2020.02.04.12.33.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Feb 2020 12:33:23 -0800 (PST) Date: Tue, 4 Feb 2020 15:33:19 -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 , virtio-dev@lists.oasis-open.org Subject: Re: Balloon pressuring page cache Message-ID: <20200204135817-mutt-send-email-mst@kernel.org> References: <20200203080520-mutt-send-email-mst@kernel.org> <5ac131de8e3b7fc1fafd05a61feb5f6889aeb917.camel@linux.intel.com> <539B606A-A0CA-4AA4-B99A-759C874A1EF8@vmware.com> <20200204033657-mutt-send-email-mst@kernel.org> <20200204114336-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-MC-Unique: zYRTd3pVM0W4xejnw9OxXw-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 Tue, Feb 04, 2020 at 05:56:22PM +0100, David Hildenbrand wrote: > [...] >=20 > >> > >> Issue 2: When called via the shrinker, (but also to fix Issue 1), it c= ould be > >> that we do have VIRTIO_BALLOON_F_MUST_TELL_HOST. I assume this means > >> (-ENOCLUE) that we have to wait until the hypervisor notifies us via t= he STOP? Or > >> for which event do we have to wait? Because there is no way to *tell h= ost* here > >> that we want to reuse a page. The hypervisor will *tell us* when we ca= n reuse pages. > >> For the shrinker it is simple: Don't use the shrinker with > >> VIRTIO_BALLOON_F_MUST_TELL_HOST :) . But to fix Issue 1, we *would* ha= ve to wait > >> until we get a STOP signal. That is not really possible because it mig= ht > >> take an infinite amount of time. > >> > >> Michael, any clue on which event we have to wait with > >> VIRTIO_BALLOON_F_MUST_TELL_HOST? IMHO, I don't think > >> VIRTIO_BALLOON_F_MUST_TELL_HOST applies to VIRTIO_BALLOON_F_FREE_PAGE_= HINT and > >> we'd better document that. It introduces complexity with no clear bene= fit. > >=20 > > I meant that we must wait for host to see the hint. Signalled via using > > the buffer. But maybe that's too far in the meaning from > > VIRTIO_BALLOON_F_MUST_TELL_HOST and we need a separate new flag for >=20 > Yes, that's what I think. >=20 > > that. Then current code won't be broken (yay!) but we need to > > document another flag that's pretty similar. >=20 > I mean, do we need a flag at all as long as there is no user? > Introducing a flag and documenting it if nobody uses it does not sound > like a work I will enjoy :) It's not the user. It's the non-orthogonality that I find inelegant. Let me try to formulate the issue, forgive me for thinking aloud (and I Cc'd virtio-dev since we are talking spec things here): The annoying thing is that with Alex's VIRTIO_BALLOON_F_REPORTING host does depend on guest not touching memory before host uses it. So functionally VIRTIO_BALLOON_F_FREE_PAGE_HINT and VIRTIO_BALLOON_F_REPORTING really are supposed to do exectly the same thing, with the differences being - VIRTIO_BALLOON_F_FREE_PAGE_HINT comes upon host's request. VIRTIO_BALLOON_F_REPORTING is initiated by guest. - VIRTIO_BALLOON_F_FREE_PAGE_HINT does not always wait for host to use the hint before touching the page. Well it almost always does, but there's an exception in the shrinker which tries to stop reporting as quickly as possible in the case of a slow host. VIRTIO_BALLOON_F_REPORTING always does. This means host can blow the page away when it sees the hint. Now the point is that with VIRTIO_BALLOON_F_REPORTING I think you really must wait for host to use the hint. But with VIRTIO_BALLOON_F_FREE_PAGE_HINT it depends on how host uses it. Something to think about, I'm not sure what is the best thing to do here. > We can simply document "VIRTIO_BALLOON_F_MUST_TELL_HOST does not apply > to FREE_PAGE_HINTING" and "with FREE_PAGE_HINTING, the guest can reuse > pages any time, without waiting for a response/ack from the hypervisor". >=20 > Thoughts? >=20 > --=20 > Thanks, >=20 > David / dhildenb