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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 927D7C49ED9 for ; Tue, 10 Sep 2019 17:52:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56CCF21479 for ; Tue, 10 Sep 2019 17:52:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56CCF21479 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E9F5A6B0006; Tue, 10 Sep 2019 13:52:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E50416B0008; Tue, 10 Sep 2019 13:52:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D65F46B000C; Tue, 10 Sep 2019 13:52:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id B63FD6B0006 for ; Tue, 10 Sep 2019 13:52:16 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 63B94180AD7C3 for ; Tue, 10 Sep 2019 17:52:16 +0000 (UTC) X-FDA: 75919755072.26.crow08_8833cc6356c1a X-HE-Tag: crow08_8833cc6356c1a X-Filterd-Recvd-Size: 6431 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Sep 2019 17:52:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7BE91AD17; Tue, 10 Sep 2019 17:52:14 +0000 (UTC) Date: Tue, 10 Sep 2019 19:52:13 +0200 From: Michal Hocko To: Alexander Duyck Cc: 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: [PATCH v9 0/8] stg mail -e --version=v9 \ Message-ID: <20190910175213.GD4023@dhcp22.suse.cz> 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.10.1 (2018-07-13) 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 10-09-19 09:05:43, Alexander Duyck 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. This analogy is indeed confusing and doesn't help to build a picture. > 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. So essentially you want to store metadata into free pages and control what the allocator can do with them? Namely buddy merging if the type doesn't match? > 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 so the baloon driver is in charge of this metadata and the allocator has to live with that. Isn't that a layer violation? -- Michal Hocko SUSE Labs