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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 B362FC43603 for ; Wed, 4 Dec 2019 17:54:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 71B2720675 for ; Wed, 4 Dec 2019 17:54:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eqtUE1no" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 71B2720675 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 12D986B0BD4; Wed, 4 Dec 2019 12:54:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 090C46B0BD5; Wed, 4 Dec 2019 12:54:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9A356B0BD6; Wed, 4 Dec 2019 12:54:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id D098E6B0BD4 for ; Wed, 4 Dec 2019 12:54:05 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 9A7873ABB for ; Wed, 4 Dec 2019 17:54:05 +0000 (UTC) X-FDA: 76228207650.11.skirt74_695d55f0e816 X-HE-Tag: skirt74_695d55f0e816 X-Filterd-Recvd-Size: 6071 Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Dec 2019 17:54:05 +0000 (UTC) Received: by mail-io1-f68.google.com with SMTP id i11so488685iol.13 for ; Wed, 04 Dec 2019 09:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Rhu4aVTP3SHJymoOSE6jn6lAKDbkxhTckaz9ubCxMc=; b=eqtUE1noyuM8BxzbDMxzyqdljYKTzHhyFZRNmOiuWMgZ7/Dr9BJ6CwwpM8gaqipYeg eZNhT3kxzMmcW6y0XsPp0JfxvYLVyKdDag+IjBXVTUmEyZfAjBOnjPPSeaqKmSDx/du7 rD00G0LPwfAnW17G3uCcucTdP61PcA4umlRWKthIIsFoZmOD5zsiELRq2GAZXI5YUrlb 2XSou9VQOQ8JxMxWYgsArcGdXoPUPg8oSJBFSNQsXbxqaQC5Eu62hl1g50owCRU7sQx3 sUPDUX/RP+p86a4V4BKSBgJxAyNOlLFiOSBnmOfwMIYVxKgwqWePihu36s741Lt/ohkO T6+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Rhu4aVTP3SHJymoOSE6jn6lAKDbkxhTckaz9ubCxMc=; b=rh7p/P+YRVucL5L7Bqy2oYlxS6hwxLa4SXsy7RDyyZU6oGUinHcrV4ypPdZf6gVmiI fT5awW435fVVr/re/3BsJs86dQVsqArs3498JmtcKDauM+hAO14AduaWfFv6zs5+kDsg 2BpFgAOeek+bBOnRGS8hMhCaPMyjpeEscmsTb3DWPJ3WMH9gaabL2NwZu8jUNvOLEF85 +Aw0bJxBw5L4rDTHK5x2H6ywIf4wC2TVVRTySJFNchmfMplLjpUK7idaulh1LmQyoXGi zIBHOWJo1PlVM/iAwbOBbjcukdl7wXut24UUhfgrFDNTq6ZNU3HdvuVFGmGp+fgEujdj IJKA== X-Gm-Message-State: APjAAAUWyDFgPXNs7cBqBzZmk8LtKY9OlzENWQFFbbYyfr90+tbn8tgE xMSkPZeX8GFCjAq8G0eUHvdztvwPBIrlFlrA8Qs= X-Google-Smtp-Source: APXvYqx0MZtv/TGr10HI8jDueGeBFRhkkLZ13EEYZPAiEPm8WPvXJzc4BDvj9q4//gK0ifWQqzWKIq0tSN5YXkqt7O4= X-Received: by 2002:a02:7f54:: with SMTP id r81mr4224567jac.121.1575482044379; Wed, 04 Dec 2019 09:54:04 -0800 (PST) MIME-Version: 1.0 References: <20191119214454.24996.66289.stgit@localhost.localdomain> <20191119214653.24996.90695.stgit@localhost.localdomain> <65de00cf-5969-ea2e-545b-2228a4c859b0@redhat.com> <20191128115436-mutt-send-email-mst@kernel.org> In-Reply-To: <20191128115436-mutt-send-email-mst@kernel.org> From: Alexander Duyck Date: Wed, 4 Dec 2019 09:53:53 -0800 Message-ID: Subject: Re: [PATCH v14 6/6] virtio-balloon: Add support for providing unused page reports to host To: "Michael S. Tsirkin" Cc: David Hildenbrand , kvm list , LKML , Matthew Wilcox , Michal Hocko , linux-mm , Andrew Morton , Mel Gorman , Vlastimil Babka , Yang Zhang , Nitesh Narayan Lal , Konrad Rzeszutek Wilk , Pankaj Gupta , Rik van Riel , lcapitulino@redhat.com, Dave Hansen , "Wang, Wei W" , Andrea Arcangeli , Paolo Bonzini , Dan Williams , Alexander Duyck , Oscar Salvador Content-Type: text/plain; charset="UTF-8" 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 Thu, Nov 28, 2019 at 9:00 AM Michael S. Tsirkin wrote: > > On Thu, Nov 28, 2019 at 04:25:54PM +0100, David Hildenbrand wrote: > > On 19.11.19 22:46, Alexander Duyck wrote: > > > From: Alexander Duyck > > > > > > Add support for the page reporting feature provided by virtio-balloon. > > > Reporting differs from the regular balloon functionality in that is is > > > much less durable than a standard memory balloon. Instead of creating a > > > list of pages that cannot be accessed the pages are only inaccessible > > > while they are being indicated to the virtio interface. Once the > > > interface has acknowledged them they are placed back into their respective > > > free lists and are once again accessible by the guest system. > > > > Maybe add something like "In contrast to ordinary balloon > > inflation/deflation, the guest can reuse all reported pages immediately > > after reporting has finished, without having to notify the hypervisor > > about it (e.g., VIRTIO_BALLOON_F_MUST_TELL_HOST does not apply)." > > Maybe we can make apply. The effect of reporting a page is effectively > putting it in a balloon then immediately taking it out. Maybe without > VIRTIO_BALLOON_F_MUST_TELL_HOST the pages can be reused before host > marked buffers used? > > We didn't teach existing page hinting to behave like this, but maybe we > should, and maybe it's not too late, not a long time passed > since it was merged, and the whole shrinker based thing > seems to have been broken ... The problem is the existing hinting implementation relies on pushing the memory to the point of OOM in order to avoid having to re-hint on pages. What it is looking for is a snapshot rather than a running tally. The page reporting bit approach would only work for the first migration. The problem is the bit is persistent and would leave unused pages flagged as reported if another migration starts so it wouldn't re-report those pages. > BTW generally UAPI patches will have to be sent to virtio-dev > mailing list before they are merged. Do you need just the QEMU patches submitted to virtio-dev or both the virtio kernel patches and the QEMU patches? One piece of feedback I got was that it was annoying that I was including virtio-dev since it requires a subscription to send to it. If you would like I could apply it on the QEMU patches which would make the changes more visible at least. Thanks. - Alex