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=-1.1 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 14D6AC49ED7 for ; Tue, 10 Sep 2019 16:05:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D4DDA206A1 for ; Tue, 10 Sep 2019 16:05:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Fo10nVgC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394096AbfIJQF5 (ORCPT ); Tue, 10 Sep 2019 12:05:57 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:45882 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730821AbfIJQF5 (ORCPT ); Tue, 10 Sep 2019 12:05:57 -0400 Received: by mail-io1-f65.google.com with SMTP id f12so38662932iog.12; Tue, 10 Sep 2019 09:05:55 -0700 (PDT) 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=VOHRoq+5f0zDDmoxjc5LrcCUbX6pSA5aom1GvfEBdqM=; b=Fo10nVgCGjb967s2Gvy7rNbxLGvFQyPQai3LMMHk9zZedD+veZSBvOOmwQSJubz6ZP tuAujd3bbR/kbJcDxXxLq07MStOXSHX/1qIcFO49nAb5M62AjF0b3yFVjA+XNCCqoEEB WliSdoQPWIq+66wv7Qo/0/p4xMBLyrD1BdExRd2/35+zdhIjOeD0flz03I1Oe76aoV9A h+0xDFdQGW2HNoXAad189kM9G4aREr7hFK4BN7X8BoO7QW2AnAzdEzWlRlvTAn+IAgFx h/DxKukXVR4eBj0Ryq0xnwI+x6E+5VbdcoJjA04pKpMjf4S2U4shxqFiG3xCBT0kEmIU vdQg== 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=VOHRoq+5f0zDDmoxjc5LrcCUbX6pSA5aom1GvfEBdqM=; b=hqQajM4ZBNf7g0egwVAEugl6PfMe+NFt59M82F5g9YdTyhClf2gI6njEgDREPukxZt l6v7oCxa4U3GN73Srea43CJ+AYZIHQJJy76LCS+rMgOygpn1mjtN0GeQjevZjxYvocS1 gjSfrRGJcpCD2qTsy1XhMnbl9NWABMa+N2SrcQ8+I/5YfJiZiuPgosDebqrOR064+bdS SHDi/a1yzBwk79OTwkO9pYnBj1S0ZsTUQ+DKJ6f73Ad1JyNe2VdjRcPl/2RHGslnPHLN VCqhqErlvY+gOHBJpGPNPzonp6eVO1w9YyfDitQthtPr+ymuCC08XLP6zDv35yVLZIJu 7/Ww== X-Gm-Message-State: APjAAAW0LNT3tbQ2n7h/CY7IaVUFIT0Skw6InghF5EIW04FaXfvukWDF ghLORvydbjPmmc5Dc7AvQ++SvpoTb1z7gttPWVI= X-Google-Smtp-Source: APXvYqwuv/pHVCWexKpkprqv1+Ti4casdnv0H37FsG/aFQFyd9UW76zxHfgdVDSoAnHjOav423k8D+xgBCR6S09zUQ4= X-Received: by 2002:a6b:ac85:: with SMTP id v127mr4562969ioe.97.1568131554878; Tue, 10 Sep 2019 09:05:54 -0700 (PDT) MIME-Version: 1.0 References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> In-Reply-To: <20190910144713.GF2063@dhcp22.suse.cz> From: Alexander Duyck Date: Tue, 10 Sep 2019 09:05:43 -0700 Message-ID: Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ To: Michal Hocko 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" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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=-1.1 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 A451DC49ED7 for ; Tue, 10 Sep 2019 16:05:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 566BF206A1 for ; Tue, 10 Sep 2019 16:05:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Fo10nVgC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 566BF206A1 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 D8F886B0006; Tue, 10 Sep 2019 12:05:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D408D6B0010; Tue, 10 Sep 2019 12:05:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7E186B0266; Tue, 10 Sep 2019 12:05:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id A6E1D6B0006 for ; Tue, 10 Sep 2019 12:05:56 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 5ACE6180AD815 for ; Tue, 10 Sep 2019 16:05:56 +0000 (UTC) X-FDA: 75919487112.12.tooth71_50e1bfd810343 X-HE-Tag: tooth71_50e1bfd810343 X-Filterd-Recvd-Size: 7370 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Sep 2019 16:05:55 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id n197so38747315iod.9 for ; Tue, 10 Sep 2019 09:05:55 -0700 (PDT) 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=VOHRoq+5f0zDDmoxjc5LrcCUbX6pSA5aom1GvfEBdqM=; b=Fo10nVgCGjb967s2Gvy7rNbxLGvFQyPQai3LMMHk9zZedD+veZSBvOOmwQSJubz6ZP tuAujd3bbR/kbJcDxXxLq07MStOXSHX/1qIcFO49nAb5M62AjF0b3yFVjA+XNCCqoEEB WliSdoQPWIq+66wv7Qo/0/p4xMBLyrD1BdExRd2/35+zdhIjOeD0flz03I1Oe76aoV9A h+0xDFdQGW2HNoXAad189kM9G4aREr7hFK4BN7X8BoO7QW2AnAzdEzWlRlvTAn+IAgFx h/DxKukXVR4eBj0Ryq0xnwI+x6E+5VbdcoJjA04pKpMjf4S2U4shxqFiG3xCBT0kEmIU vdQg== 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=VOHRoq+5f0zDDmoxjc5LrcCUbX6pSA5aom1GvfEBdqM=; b=WuvydxDuKco++GZY+/Pr+DaWCT1UszQEIpcxv64GRbWV9nsmQGFkoH+lTgu9BhJFcl vSFAZu1gmNy178Vn84yziVr/tsgeOTzbVFJT8sk4HypFAYdyCcXLMq6Y72vOdLDZ0F4r VxeNoWTkpBRjZzuk/Q6dn1Qf1UwCjhPr3WIR7IpiG7TzufofcC/2XnC/tGk8wGy52MMl DLvqorlMNzfgepCG0kdD/0dYoblZ34z9avIcOh1phgSUEfeyG2MiOzFf4F3s9Cd8eHRT 7s5FmihEcdQL6rRToOxJ+By6aUky1www5MDOxJ/UjJYKUb+rGRbYAn8KWYt/YbbyNrAZ jlSA== X-Gm-Message-State: APjAAAVI3HZkBLR4TEtdB7u0++VzGF1U+f6cUNqqqKSkF+BNuwuSHmqT gtQIcYHD0bIyC1H1t7c4p//89+KweYOF8Gzw7fM= X-Google-Smtp-Source: APXvYqwuv/pHVCWexKpkprqv1+Ti4casdnv0H37FsG/aFQFyd9UW76zxHfgdVDSoAnHjOav423k8D+xgBCR6S09zUQ4= X-Received: by 2002:a6b:ac85:: with SMTP id v127mr4562969ioe.97.1568131554878; Tue, 10 Sep 2019 09:05:54 -0700 (PDT) MIME-Version: 1.0 References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> In-Reply-To: <20190910144713.GF2063@dhcp22.suse.cz> From: Alexander Duyck Date: Tue, 10 Sep 2019 09:05:43 -0700 Message-ID: Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ To: Michal Hocko 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" 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 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. 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=-1.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 6BA48C49ED8 for ; Tue, 10 Sep 2019 16:06:06 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3B2E9206A1 for ; Tue, 10 Sep 2019 16:06:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VOBey8eB"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Fo10nVgC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B2E9206A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qJPdlunc9L3NRy3S/Zeha9+9VyyKCAhYOSft6SXFYa0=; b=VOBey8eB6QyS9U I4lZ0dn9jeNI2+ezuO1QanC+vbrH/3fbZstarteue+xpPs2nM85zju2HlT3+GBqWD5n22E7yYIRR8 NnKGLyVwIOdVaH4TMpbgFB2HrfD5NRyXH2qNMxu9AVh75PBms+XHqRoICnuyCjaryZuqEDTHFgQh9 020FtL54wca1EQuouwi0ElnqmrffCObbzNa8bxWUPtl4YKuleeslkVU5OC3aSE67ZkZcHek6Sk36L /FFr4/Pz63jDoEzOZk+4DJZTHpme3tu2q6rM0vujWEnEqM57n0K9xG9QrJt7vldKmrkzPHn7I4php xpYoBO6nmSXvIKh6bXJQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i7ieV-0003z5-Cv; Tue, 10 Sep 2019 16:05:59 +0000 Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i7ieR-0003xI-S0 for linux-arm-kernel@lists.infradead.org; Tue, 10 Sep 2019 16:05:57 +0000 Received: by mail-io1-xd44.google.com with SMTP id b136so38791995iof.3 for ; Tue, 10 Sep 2019 09:05:55 -0700 (PDT) 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=VOHRoq+5f0zDDmoxjc5LrcCUbX6pSA5aom1GvfEBdqM=; b=Fo10nVgCGjb967s2Gvy7rNbxLGvFQyPQai3LMMHk9zZedD+veZSBvOOmwQSJubz6ZP tuAujd3bbR/kbJcDxXxLq07MStOXSHX/1qIcFO49nAb5M62AjF0b3yFVjA+XNCCqoEEB WliSdoQPWIq+66wv7Qo/0/p4xMBLyrD1BdExRd2/35+zdhIjOeD0flz03I1Oe76aoV9A h+0xDFdQGW2HNoXAad189kM9G4aREr7hFK4BN7X8BoO7QW2AnAzdEzWlRlvTAn+IAgFx h/DxKukXVR4eBj0Ryq0xnwI+x6E+5VbdcoJjA04pKpMjf4S2U4shxqFiG3xCBT0kEmIU vdQg== 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=VOHRoq+5f0zDDmoxjc5LrcCUbX6pSA5aom1GvfEBdqM=; b=MgNGW/FbfZ0fbAeVJ4QmMIAi5cTax0Tv4NlvxhJF9/OTRizP9Eb7tkdg1nyVA11o21 G+4D9l39U0PmecbC3Lbs/4yg9eMk18NdifpDv660kKLU7qpucZF0M/ot0+pTwPza8kDf M8vDU4PU+9EEBAVnEZf1ycL+Y/jwMDv5RyA9pMJw0G/xcTUShmNmwMt9VWk++8GocU4/ UlOMCZJ7M5G25aS0VKUFaVel1Wo8B3zWQdOopcJn1H8Zf5EW06GNJHvHKVN6QgAGmqVq ZyoAa7T3rkbdjZF4A/vEfu/qOrpVuWFpdlbVJ/6XBvXJYJ4rW9FvnMWwCPlL3354P84W I8WQ== X-Gm-Message-State: APjAAAUxUknPSLjElBucnyzQ02DNWo8s21CZ0iiM/1jmxFifafOHnP/7 gjoq9tqOwPw17j/e2hY5rvWe/xY2GZL0ar/Y4jA= X-Google-Smtp-Source: APXvYqwuv/pHVCWexKpkprqv1+Ti4casdnv0H37FsG/aFQFyd9UW76zxHfgdVDSoAnHjOav423k8D+xgBCR6S09zUQ4= X-Received: by 2002:a6b:ac85:: with SMTP id v127mr4562969ioe.97.1568131554878; Tue, 10 Sep 2019 09:05:54 -0700 (PDT) MIME-Version: 1.0 References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> In-Reply-To: <20190910144713.GF2063@dhcp22.suse.cz> From: Alexander Duyck Date: Tue, 10 Sep 2019 09:05:43 -0700 Message-ID: Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \ To: Michal Hocko X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190910_090555_938022_8FBBF196 X-CRM114-Status: GOOD ( 29.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Yang Zhang , Pankaj Gupta , kvm list , David Hildenbrand , Catalin Marinas , lcapitulino@redhat.com, linux-mm , Alexander Duyck , will@kernel.org, Andrea Arcangeli , virtio-dev@lists.oasis-open.org, "Michael S. Tsirkin" , Matthew Wilcox , "Wang, Wei W" , ying.huang@intel.com, Rik van Riel , Konrad Rzeszutek Wilk , Dan Williams , linux-arm-kernel@lists.infradead.org, Oscar Salvador , Nitesh Narayan Lal , Dave Hansen , LKML , Paolo Bonzini , Andrew Morton , Fengguang Wu , "Kirill A. Shutemov" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6103-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 22EBC985B0B for ; Tue, 10 Sep 2019 16:05:57 +0000 (UTC) MIME-Version: 1.0 References: <20190907172225.10910.34302.stgit@localhost.localdomain> <20190910124209.GY2063@dhcp22.suse.cz> <20190910144713.GF2063@dhcp22.suse.cz> In-Reply-To: <20190910144713.GF2063@dhcp22.suse.cz> From: Alexander Duyck Date: Tue, 10 Sep 2019 09:05:43 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \ To: Michal Hocko 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" List-ID: 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. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org