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 803E6C352A3 for ; Tue, 11 Feb 2020 14:17:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32D1320848 for ; Tue, 11 Feb 2020 14:17:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="a9gdnCCr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32D1320848 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 B9FA96B02D8; Tue, 11 Feb 2020 09:17:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B4F2D6B02D9; Tue, 11 Feb 2020 09:17:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A17036B02DA; Tue, 11 Feb 2020 09:17:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id 8A9566B02D8 for ; Tue, 11 Feb 2020 09:17:53 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 22E83180ACEEB for ; Tue, 11 Feb 2020 14:17:53 +0000 (UTC) X-FDA: 76478050026.28.owner54_67506b71ab39 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 5667F25F4D for ; Tue, 11 Feb 2020 14:07:25 +0000 (UTC) X-HE-Tag: owner54_67506b71ab39 X-Filterd-Recvd-Size: 7272 Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 11 Feb 2020 14:07:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581430043; 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=8Gy0zVxTid7V+iq6YsgIJQU70L5wM26+oR0lwZOcfH4=; b=a9gdnCCrUNkJElTxfaaWJU9wkxe9f2WKRY5S6oUF850VvXmB7lWXudkjNJRWI6aVuxbobN cNdZNzcekVi2IGsNI91lm3amMdYKjZUxjblncIurunA+DoSvswZnHNdfnO27c+jKnZb3i8 HBT9NaZpntnpl6gcKYAmCEZDBD3UMmI= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-14-AJNzgFpCNbmI79N6asUqcQ-1; Tue, 11 Feb 2020 09:07:21 -0500 Received: by mail-qk1-f200.google.com with SMTP id d134so7139508qkc.0 for ; Tue, 11 Feb 2020 06:07:21 -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=INu84orqc9+je081poLUqhp5eUlqzmj/i/n4RyB/kg0=; b=bFacI0nxDIn5qMfxqPmf81lDCfVUaAGx9CR6o3Af/Kp3gV1fzFDduMbZORlPy+97LZ uQ2icB/0VzFvsZbNNZ18a+4FuaP7FF9iof/Xbnl8nt2MNG7xV0AkORJ98LvHei7dCvN6 TIlQgwifmWMYG+zUvFs+JB9EO83/JAtkU5HfL7q+pMsBv5E1kPoShqvAMy0g0zf1C503 y74agV6j1MGMY2YMbI91ol/AQ6+ic4H0mlIvAAgP5EynvWqh0awETrWRPh1usDlmz6Bl 2pse6Gtdjbmpb40CfQuxafzHDMsjCgIE510gaFz1KzC7VXUAFeum8IUmGAeaeTD0Jn+V O9tg== X-Gm-Message-State: APjAAAUJs//mD1M6LLxmbfhY5206miUaUJRSI4fLOOHqACZLWyqIYhc9 g+3VEVHScQNcnB84HvKgVbvKfFz2uW0ynwrONsl9H0z+VQeZoLMLxJhwrHMUKwOaMyyCH3YDgOW a7bnvZjDYiC4= X-Received: by 2002:a37:9e09:: with SMTP id h9mr6306042qke.176.1581430040982; Tue, 11 Feb 2020 06:07:20 -0800 (PST) X-Google-Smtp-Source: APXvYqzu8Y9MsH8YO9REysQ9nYFhCJuec8Q3jBv6o6L1bwS7xwhDk3Sc7yQGpQut6djeRWTzM+X5sw== X-Received: by 2002:a37:9e09:: with SMTP id h9mr6306002qke.176.1581430040713; Tue, 11 Feb 2020 06:07:20 -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 z1sm2150280qtq.69.2020.02.11.06.07.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2020 06:07:19 -0800 (PST) Date: Tue, 11 Feb 2020 09:07:12 -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: <20200211090052-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> MIME-Version: 1.0 In-Reply-To: X-MC-Unique: AJNzgFpCNbmI79N6asUqcQ-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 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 alon= e. > >=20 > > Not sure what do you mean by "left alone here". Could you clarify? >=20 > Don't try to unify handling like I proposed below, because it's > semantics are special. >=20 > >=20 > >> VIRTIO_BALLOON_F_REPORTING is nothing but a more advanced inflate, rig= ht > >> (sg, inflate based on size - not "virtio pages")? > >=20 > >=20 > > Not exactly - it's also initiated by guest as opposed to host, and > > not guided by the ballon size request set by the host. >=20 > 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. Hmm how isn't it? num_pages is the only way to inflate/deflate. Spec also says: The device is driven either by the receipt of a configuration change notifi= cation, or by changing guest memory needs, such as performing memory compaction or responding to out of memory = conditions. so ignoring compaction/oom (later is under-specified, not a good example to follow) yes inflate/deflate are tied to host specified configuration. > > And uses a dedicated queue to avoid blocking other functionality ... >=20 > True, but the other queues also don't allow for an easy extension > AFAIKS, so that's another reason. >=20 > >=20 > > I really think this is more like an inflate immediately followed by def= late. >=20 > Depends on how you look at it. As inflate/deflate is not glued to the > balloon size (the guest updates the size manually), it's not obvious. >=20 > E.g., in QEMU, a deflate is just a performance improvement > ("MADV_WILLNEED") - in that regard, it's more like an optional deflation. >=20 > [...] >=20 > >=20 > > I'd rather wait until we have a usecase and preferably a POC > > showing it helps before we add optional deflate ... > > For now I personally am fine with just making this go ahead as is, > > and imply SG and OPTIONAL_DEFLATE just for this VQ. >=20 > Also fine with me, you asked about if we can abstract any of this if I > am not wrong :) So this was my take. >=20 > >=20 > > Do you feel strongly we need to bring this up to a TC vote? >=20 > Not really. People have been asking about how to inflate/deflate huge > pages a long time ago (comes with different challenges - e.g., balloon > compaction). looked like this interface could have been reused for this > as well. >=20 > But yeah, I am not a fan of virtio-balloon and the whole inflate/deflate > thingy. So at least I don't see a need to extend the inflate/deflate > capability. >=20 > Free page reporting is a different story (and the semantics require no > inflate/deflate/balloon size) - it could have been moved to > virtio-whatever without any issues. So I am fine with this. >=20 > --=20 > Thanks, >=20 > David / dhildenb