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 A9D1EC352A3 for ; Tue, 11 Feb 2020 14:48:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56D68206DB for ; Tue, 11 Feb 2020 14:48:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GLIOYVJC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56D68206DB 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 EBD676B02E3; Tue, 11 Feb 2020 09:48:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E6DC26B02E5; Tue, 11 Feb 2020 09:48:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5C2A6B02E6; Tue, 11 Feb 2020 09:48:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B9C6A6B02E3 for ; Tue, 11 Feb 2020 09:48:55 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 444C48248076 for ; Tue, 11 Feb 2020 14:48:55 +0000 (UTC) X-FDA: 76478128230.04.floor07_4dd30f621895d X-HE-Tag: floor07_4dd30f621895d X-Filterd-Recvd-Size: 7315 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Tue, 11 Feb 2020 14:48:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581432534; 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=/8PbnTfM6o6gGVpijYhdLSbJc/olXrdXJq2kjGukwP0=; b=GLIOYVJCdcMPjJ+iIzDE8JcLwGM0T/RvS69wYLxEjGOQ2djnybijxwHTKi5ZLBTZ/BhU88 AwXDavcZivHWfGXUa0x+t4OJYm2AYXiGdABb2KOziXufMt8HRWIWJiMwB1aIi2Ol+1uXcp vxTprkKnBOGzAeawc3gYqBDf0ZAKEEU= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-394-umRiTDgbNri62VklGdiDgA-1; Tue, 11 Feb 2020 09:48:52 -0500 Received: by mail-qk1-f199.google.com with SMTP id z64so7200204qke.10 for ; Tue, 11 Feb 2020 06:48:52 -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=7nfesydZoKg7wB4eAKrBh2n+G/3uidxo6nvSZCLKjmc=; b=ehil8wGnXfRDF0C9DCSXxS0nYzuXSuuhVUYil5fu/r+3r7HGP84zNKw3qrr2PdWpBU Jc8AupUmac/b80DATjJULKwr67uCWZaOHigodHUn1yQR9qoZXF5BxGP0IgsUbxQNwKZy F8CbuI4Wo52MolFFoJ5OCgcvu3tdc41aYmUuBnw3nrwzfxsBp9El3EeT4VOWuEJaNl+b Xs04XQs7qLWh3DKUswAVRjJMcTdJikHRvLPvlETwSG3Jx9OXY1/XMv/E1TEzsgCTeCnn pFCdovjZH/xxvdJduYaNR0W39bDGnwZ9lUMIf+g80kSF7GNAexAa24eOn2AhTXGDNdHP ygQw== X-Gm-Message-State: APjAAAXW8KgydT8zM11ujAfaYesrfbOMPzTnPCUGADLduOoRw736GzDq SP+4gdaFA2mldnTiH4FRZFHTtQ/kQTHyDsfoUUTM45CbjsHvwALltm4Ven00Tdaf7NB5qXvUDnO snyXQqaOxtG0= X-Received: by 2002:a37:903:: with SMTP id 3mr3033660qkj.388.1581432532234; Tue, 11 Feb 2020 06:48:52 -0800 (PST) X-Google-Smtp-Source: APXvYqyUijSiSAKNmsG0wLQ4U4khGmkyoOv0nfwK5grGPQCYnR4o3HHFiCAQ1Fz9hORrM7QHvkhP8g== X-Received: by 2002:a37:903:: with SMTP id 3mr3033633qkj.388.1581432531928; Tue, 11 Feb 2020 06:48:51 -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 p18sm2137225qkp.47.2020.02.11.06.48.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2020 06:48:51 -0800 (PST) Date: Tue, 11 Feb 2020 09:48:44 -0500 From: "Michael S. Tsirkin" To: David Hildenbrand Cc: Alexander Duyck , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, willy@infradead.org, mhocko@kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, mgorman@techsingularity.net, vbabka@suse.cz, yang.zhang.wz@gmail.com, nitesh@redhat.com, konrad.wilk@oracle.com, pagupta@redhat.com, riel@surriel.com, lcapitulino@redhat.com, dave.hansen@intel.com, wei.w.wang@intel.com, aarcange@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, alexander.h.duyck@linux.intel.com, osalvador@suse.de Subject: Re: [PATCH v16.1 6/9] virtio-balloon: Add support for providing free page reports to host Message-ID: <20200211094357-mutt-send-email-mst@kernel.org> References: <20200122173040.6142.39116.stgit@localhost.localdomain> <20200122174347.6142.92803.stgit@localhost.localdomain> <20200211063441-mutt-send-email-mst@kernel.org> <20200211090052-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-MC-Unique: umRiTDgbNri62VklGdiDgA-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 11, 2020 at 03:31:18PM +0100, David Hildenbrand wrote: > On 11.02.20 15:07, Michael S. Tsirkin wrote: > > On Tue, Feb 11, 2020 at 01:19:31PM +0100, David Hildenbrand wrote: > >>>> > >>>> Did you see the discussion regarding unifying handling of > >>>> inflate/deflate/free_page_hinting_free_page_reporting, requested by > >>>> Michael? I think free page reporting is special and shall be left al= one. > >>> > >>> Not sure what do you mean by "left alone here". Could you clarify? > >> > >> Don't try to unify handling like I proposed below, because it's > >> semantics are special. > >> > >>> > >>>> VIRTIO_BALLOON_F_REPORTING is nothing but a more advanced inflate, r= ight > >>>> (sg, inflate based on size - not "virtio pages")? > >>> > >>> > >>> Not exactly - it's also initiated by guest as opposed to host, and > >>> not guided by the ballon size request set by the host. > >> > >> True, but AFAIKS you could use existing INFLATE/DEFLATE in a similar > >> way. There is no way for the hypervisor to nack a request. The balloon > >> size is not glued to inflate/deflate requests. The guests manually > >> updates it. > >=20 > > Hmm how isn't it? num_pages is the only way to inflate/deflate. >=20 > Usually, guests are nice and respond to num_pages changes in an > appropriate way, except: > - Triggering deflate: Unload the driver. Suspend/hibernate. OOM. > (+ Reboot, although that's special) > - Triggering inflate + deflate: Simple balloon compaction / page > migration. These are all real situations but balloon always has been best effort. > But that's not what I meant. >=20 > "actual" is updated by the guest, not by the host. So the "actual > balloon size" is set by the guest. It's not glued to inflation/deflation > requests. "num_pages" is the host request. Well the expectation is that as long as guest has ample available memory, when num_pages changes then guest starts sending inflate/deflate requests, until actual matches num_pages. If it does not match, and we wait and it still doesn't, then something unusual happened. People do depend on that behaviour. > AFAIKs, the guest could inflate/deflate (esp. temporarily) and > communicate via "actual" the actual balloon size as he sees it. OK so you want hinted but unused pages counted, and reported in "actual"? That's a vmexit before each page use ... > > Spec also says: > > The device is driven either by the receipt of a configuration change no= tification, or by changing guest memory > > needs, such as performing memory compaction or responding to out of mem= ory conditions. > >=20 > > so ignoring compaction/oom (later is under-specified, not a good exampl= e > > to follow) yes inflate/deflate are tied to host specified configuration > Yes, "num_pages" is the host request. But I'd say the statement (esp. > "the device is driven by") in the spec is rather weak. It does not > explicitly state when inflation/deflation is allowed IMHO. Right since it's all best effort anyway. > --=20 > Thanks, >=20 > David / dhildenb