Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5826939ybe; Tue, 10 Sep 2019 09:21:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqzPSrtY9lF3Aj5h0Skx85qBTCvznuqXg59XAyedQBUKz5I1eJtCZ8gM+McUEjCQVfb1ZTOI X-Received: by 2002:a17:906:1694:: with SMTP id s20mr25403196ejd.262.1568132462815; Tue, 10 Sep 2019 09:21:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568132462; cv=none; d=google.com; s=arc-20160816; b=CIOmwo5wdrvlt5F75Qskk9foKf8ns9NB0z5UmDldE+ITOVQpdkkW779OFJBiYq0a4w 4uW2Aqngz3aJARq0PqoYX8c131xPdnaO5DPK5zFOAISR+cXXgML+u2mj+r4ZoClf9I2w 57RAVurDCUHsVJPNd6Orqc9H3NRZ/5lUmsoVuV134TNcxWbsCE6Q0T1d63o2NR3a4GbI jqxosKT//7PV9zH4XYRVd5KNuC1h+xjI7lhTwnjZzp2y9uLShgmTfnTGMgKZAFw9ds9h 6Ot/Ov5qahIdyWzz3Oia1/gWPF4NftcOGFFADaWYKAlWVMnwKjPb7ZYxNbIMXoo6QKe5 /2lA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ZMxJrCQGVzMWebctLqGetWEs3DrmDHhMmWWrO0NR8Kk=; b=L1VGqzCtEgZJt5ujvFAACMSIE9B1FCoxrI8M3x/EsvsuJy9vUSD3JSxJ/liT7g/2Kg 9wvh7Qe9+N655zUrCGq89crq1YmQKzBOnaP8ahFwV4A1nmaqngZkPN7WL70lM9cL3xiZ w8bGkhMOh8TNpQdIkhWf9r/f95zTlU0anAcyrSjUwDvnkev0TPcE+AaTJsjcEErAOidh XpDoVBIPlEaEo1ZAOEM/vEqhLa8BgaTN/9LP1keKVx7ni4/JkuUWC2ukRaHD1sXoxNCX CQiBJ3GVHpmiF2VFl1TWjVlqp3ThO8SAtXzeQ0Pl3uvmsUYM8MEzRXonWVsIcErobT1x CnDA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l12si5382013ejc.390.2019.09.10.09.20.38; Tue, 10 Sep 2019 09:21:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394164AbfIJQSk (ORCPT + 99 others); Tue, 10 Sep 2019 12:18:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48516 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729971AbfIJQSj (ORCPT ); Tue, 10 Sep 2019 12:18:39 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CE513882EF; Tue, 10 Sep 2019 16:18:38 +0000 (UTC) Received: from work-vm (ovpn-117-238.ams2.redhat.com [10.36.117.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A45E5DA21; Tue, 10 Sep 2019 16:18:20 +0000 (UTC) Date: Tue, 10 Sep 2019 17:18:18 +0100 From: "Dr. David Alan Gilbert" To: Alexander Duyck Cc: Michal Hocko , virtio-dev@lists.oasis-open.org, kvm list , "Michael S. Tsirkin" , Catalin Marinas , David Hildenbrand , Dave Hansen , LKML , Matthew Wilcox , linux-mm , Andrew Morton , will@kernel.org, linux-arm-kernel@lists.infradead.org, Oscar Salvador , Yang Zhang , Pankaj Gupta , Konrad Rzeszutek Wilk , Nitesh Narayan Lal , Rik van Riel , lcapitulino@redhat.com, "Wang, Wei W" , Andrea Arcangeli , ying.huang@intel.com, Paolo Bonzini , Dan Williams , Fengguang Wu , Alexander Duyck , "Kirill A. Shutemov" Subject: Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \ Message-ID: <20190910161818.GF2797@work-vm> References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 10 Sep 2019 16:18:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Alexander Duyck (alexander.duyck@gmail.com) wrote: > On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko wrote: > > > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko wrote: > > > > > > > > I wanted to review "mm: Introduce Reported pages" just realize that I > > > > have no clue on what is going on so returned to the cover and it didn't > > > > really help much. I am completely unfamiliar with virtio so please bear > > > > with me. > > > > > > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote: > > > > [...] > > > > > This series provides an asynchronous means of reporting to a hypervisor > > > > > that a guest page is no longer in use and can have the data associated > > > > > with it dropped. To do this I have implemented functionality that allows > > > > > for what I am referring to as unused page reporting > > > > > > > > > > The functionality for this is fairly simple. When enabled it will allocate > > > > > statistics to track the number of reported pages in a given free area. > > > > > When the number of free pages exceeds this value plus a high water value, > > > > > currently 32, it will begin performing page reporting which consists of > > > > > pulling pages off of free list and placing them into a scatter list. The > > > > > scatterlist is then given to the page reporting device and it will perform > > > > > the required action to make the pages "reported", in the case of > > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED > > > > > and as such they are forced out of the guest. After this they are placed > > > > > back on the free list, > > > > > > > > And here I am reallly lost because "forced out of the guest" makes me > > > > feel that those pages are no longer usable by the guest. So how come you > > > > can add them back to the free list. I suspect understanding this part > > > > will allow me to understand why we have to mark those pages and prevent > > > > merging. > > > > > > Basically as the paragraph above mentions "forced out of the guest" > > > really is just the hypervisor calling MADV_DONTNEED on the page in > > > question. So the behavior is the same as any userspace application > > > that calls MADV_DONTNEED where the contents are no longer accessible > > > from userspace and attempting to access them will result in a fault > > > and the page being populated with a zero fill on-demand page, or a > > > copy of the file contents if the memory is file backed. > > > > As I've said I have no idea about virt so this doesn't really tell me > > much. Does that mean that if somebody allocates such a page and tries to > > access it then virt will handle a fault and bring it back? > > Actually I am probably describing too much as the MADV_DONTNEED is the > hypervisor behavior in response to the virtio-balloon notification. A > more thorough explanation of it can be found by just running "man > madvise", probably best just to leave it at that since I am probably > confusing things by describing hypervisor behavior in a kernel patch > set. > > For the most part all the page reporting really does is provide a way > to incrementally identify unused regions of memory in the buddy > allocator. That in turn is used by virtio-balloon in a polling thread > to report to the hypervisor what pages are not in use so that it can > make a decision on what to do with the pages now that it knows they > are unused. > > All this is providing is just a report and it is optional if the > hypervisor will act on it or not. If the hypervisor takes some sort of > action on the page, then the expectation is that the hypervisor will > use some sort of mechanism such as a page fault to discover when the > page is used again. OK, that's interestingly different (but OK) from some other schemes that hav ebeen described which *require* the guest to somehow indicate the page is in use before starting to use the page again. Dave > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK