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 79132C352A3 for ; Wed, 12 Feb 2020 01:19:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4965320842 for ; Wed, 12 Feb 2020 01:19:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CkaG5Gej" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728190AbgBLBT3 (ORCPT ); Tue, 11 Feb 2020 20:19:29 -0500 Received: from mail-io1-f65.google.com ([209.85.166.65]:41019 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728070AbgBLBT3 (ORCPT ); Tue, 11 Feb 2020 20:19:29 -0500 Received: by mail-io1-f65.google.com with SMTP id m25so296645ioo.8; Tue, 11 Feb 2020 17:19:27 -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=kAE5YK5ptxtbuQnOU15dRXQpkp+DTRx4GZkHUX5A+v4=; b=CkaG5GejNspicmv5zvT1An89YyaxAHBpKAQi9dtfonhl+Zk5q48JqbkKpUo6aTlB22 sARdQCNbVC4rH8Uln3FSNqeOBnz2DAD045ne0kgzcCVV/7WzWpqC5V9XevHd94bTrW8P D9cIIn89CGhGk/KupLMB1QVvp50C+QcIRcB8jcAEAj8Yhpca/SccHGIL5A/3dwZ1Q0Ws Q1KXsHKFsXiiqFugKo4f/FogTh84MC7+5CfIMkN05ryb/AJp86ZXX1ijbk9cg7bQ4xMR AoC/WA/+XhC7rAXGYIZCpc1M64fQoj5hpYDJzPWSYL3MUriEnDFMIAZPxVVXviBc9KSE 9f0g== 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=kAE5YK5ptxtbuQnOU15dRXQpkp+DTRx4GZkHUX5A+v4=; b=i62usv/IeC5WKJ7QCZtCFM4mg1yO3DDmx+QBiUQU+X2Q2SCDvJFdX7gLvGUsS+MAA8 c0S19/m+e835rf3B16vp+54h4RmCIbnvvjlXH4wDo28Ek71bBEBkjwwNPiGQ2Hrf0qED hixlEh7dOrBJvSiAZk8rjp3DhyDi9l64VYeMvnmQoTyp91+NGs+BnzEYULzfVNyaYY0S 88wobGhxus67ULJY8GTyG5EaSUxXG2Owc7GfV9dvELHiLLXexjQYSgzCd3unhWWmKxfY cTozsTAuWMQy0mPG0hm9XfiLMFPklS7xnLLQ6bXZ0j2egBPjoZ0Wr3/fD1HP4Jpd0nnF ko0g== X-Gm-Message-State: APjAAAWpWuSFGFqB017Zenjaqt74XcTLCmKhhX9orQCu4QH66z6nN3n1 FN2bThJMRPBMerYt4m0OZsqFBkfcOLSZq8fv43E= X-Google-Smtp-Source: APXvYqynLPmdSNLhpziF/vijEhxYQZVqmzYbFPwtfE+PuECGlAsnYff4gawpAvHezgL8NLLeMoqRQ7S7rFoPF+/bARE= X-Received: by 2002:a6b:6e06:: with SMTP id d6mr15011186ioh.95.1581470366660; Tue, 11 Feb 2020 17:19:26 -0800 (PST) MIME-Version: 1.0 References: <20200211224416.29318.44077.stgit@localhost.localdomain> <20200211150510.ca864143284c8ccaa906f524@linux-foundation.org> <20200211161927.1068232d044e892782aef9ae@linux-foundation.org> In-Reply-To: <20200211161927.1068232d044e892782aef9ae@linux-foundation.org> From: Alexander Duyck Date: Tue, 11 Feb 2020 17:19:15 -0800 Message-ID: Subject: Re: [PATCH v17 0/9] mm / virtio: Provide support for free page reporting To: Andrew Morton Cc: Alexander Duyck , kvm list , David Hildenbrand , "Michael S. Tsirkin" , LKML , linux-mm , Mel Gorman , Yang Zhang , Pankaj Gupta , Konrad Rzeszutek Wilk , Nitesh Narayan Lal , Rik van Riel , Matthew Wilcox , lcapitulino@redhat.com, Dave Hansen , "Wang, Wei W" , Andrea Arcangeli , Paolo Bonzini , Dan Williams , Michal Hocko , Vlastimil Babka , Oscar Salvador 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, Feb 11, 2020 at 4:19 PM Andrew Morton wrote: > > On Tue, 11 Feb 2020 15:55:31 -0800 Alexander Duyck wrote: > > > On the host I just have to monitor /proc/meminfo and I can see the > > difference. I get the following results on the host, in the enabled case > > it takes about 30 seconds for it to settle into the final state since I > > only report page a bit at a time: > > Baseline/Applied > > MemTotal: 131963012 kB > > MemFree: 95189740 kB > > > > Enabled: > > MemTotal: 131963012 kB > > MemFree: 126459472 kB > > > > This is what I was referring to with the comment above. I had a test I was > > running back around the first RFC that consisted of bringing up enough VMs > > so that there was a bit of memory overcommit and then having the VMs in > > turn run memhog. As I recall the difference between the two was something > > like a couple minutes to run through all the VMs as the memhog would take > > up to 40+ seconds for one that was having to pull from swap while it took > > only 5 to 7 seconds for the VMs that were all running the page hinting. > > > > I had referenced it here in the RFC: > > https://lore.kernel.org/lkml/20190204181118.12095.38300.stgit@localhost.localdomain/ > > > > I have been verifying the memory has been getting freed but didn't feel > > like the test added much value so I haven't added it to the cover page for > > a while since the time could vary widely and is dependent on things like > > the disk type used for the host swap since my SSD is likely faster than > > spinning rust, but may not be as fast as other SSDs on the market. Since > > the disk speed can play such a huge role I wasn't comfortable posting > > numbers since the benefits could vary so widely. > > OK, thanks. I'll add the patches to the mm pile. The new > mm/page_reporting.c is unreviewed afaict, so I guess you own that for > now ;) I will see what I can do to get some additional review of those patches. There has been some review, but I rewrote that block after suggestions as I had to split it out over several patches to account for the gains from the changes in patches 7 and 8. > It would be very nice to get some feedback from testers asserting "yes, > this really helped my workload" but I understand this sort of testing > is hard to obtain at this stage. Without the QEMU patches applied there isn't much that this patch set can do on its own, so that is another piece I have to work on. Yet another reason to make sure it does no harm if it is not enabled. So far the one that surprised me the most is that somebody from Huawei was working to add device pass-thru support to it already. https://lore.kernel.org/lkml/1578408399-20092-1-git-send-email-weiqi4@huawei.com/ Thanks. - Alex 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 54A7EC35242 for ; Wed, 12 Feb 2020 01:19:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E24F02082F for ; Wed, 12 Feb 2020 01:19:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CkaG5Gej" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E24F02082F 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 912E16B0385; Tue, 11 Feb 2020 20:19:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C3CB6B0387; Tue, 11 Feb 2020 20:19:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7DA126B0388; Tue, 11 Feb 2020 20:19:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 6672C6B0385 for ; Tue, 11 Feb 2020 20:19:28 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id F266845BB for ; Wed, 12 Feb 2020 01:19:27 +0000 (UTC) X-FDA: 76479717174.17.shock47_357ed00307327 X-HE-Tag: shock47_357ed00307327 X-Filterd-Recvd-Size: 6469 Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Feb 2020 01:19:27 +0000 (UTC) Received: by mail-io1-f65.google.com with SMTP id d15so325277iog.3 for ; Tue, 11 Feb 2020 17:19:27 -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=kAE5YK5ptxtbuQnOU15dRXQpkp+DTRx4GZkHUX5A+v4=; b=CkaG5GejNspicmv5zvT1An89YyaxAHBpKAQi9dtfonhl+Zk5q48JqbkKpUo6aTlB22 sARdQCNbVC4rH8Uln3FSNqeOBnz2DAD045ne0kgzcCVV/7WzWpqC5V9XevHd94bTrW8P D9cIIn89CGhGk/KupLMB1QVvp50C+QcIRcB8jcAEAj8Yhpca/SccHGIL5A/3dwZ1Q0Ws Q1KXsHKFsXiiqFugKo4f/FogTh84MC7+5CfIMkN05ryb/AJp86ZXX1ijbk9cg7bQ4xMR AoC/WA/+XhC7rAXGYIZCpc1M64fQoj5hpYDJzPWSYL3MUriEnDFMIAZPxVVXviBc9KSE 9f0g== 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=kAE5YK5ptxtbuQnOU15dRXQpkp+DTRx4GZkHUX5A+v4=; b=AzalZ9cMZTVDs1Em3/jpEYvyvmEONcynH6cuHYxsWc3/bgfjltq0p6YRt+iw2uZHp4 dCP5ZisaBxW9dEbPQ3YOe+j0xO203b1VKOaxBuNfTqyMf8fgRFpmLK6jadbIWjH/A+Jx llOUvJh2r+Tikj+/uS1s/Fws0IoC5fEVc69GshmvclXP6YjsLuoMD9xhrwc3+vftm+Ok aNKpHxRYIuCXBX2B9Gmw0y/ScP1Zz8Kr86bJuL16amxs4kJmB1L3mEo/GDHvhtmOOOZ4 Vo2Xfq2Vh2LSDLonkbVnjG6mVk6hv8zpyI/Fg0RZ/xR4ZgBz3nhPJvh5nCEisIA4shPZ qQXQ== X-Gm-Message-State: APjAAAXVh9Dcj5456gtfVkn/VuWJJtRmPKI96xn5PsSZV68uRIiaVIYp hEVqsjLejLwO2Qp4scV1j/JkwJZoqkDVIBPQiDc= X-Google-Smtp-Source: APXvYqynLPmdSNLhpziF/vijEhxYQZVqmzYbFPwtfE+PuECGlAsnYff4gawpAvHezgL8NLLeMoqRQ7S7rFoPF+/bARE= X-Received: by 2002:a6b:6e06:: with SMTP id d6mr15011186ioh.95.1581470366660; Tue, 11 Feb 2020 17:19:26 -0800 (PST) MIME-Version: 1.0 References: <20200211224416.29318.44077.stgit@localhost.localdomain> <20200211150510.ca864143284c8ccaa906f524@linux-foundation.org> <20200211161927.1068232d044e892782aef9ae@linux-foundation.org> In-Reply-To: <20200211161927.1068232d044e892782aef9ae@linux-foundation.org> From: Alexander Duyck Date: Tue, 11 Feb 2020 17:19:15 -0800 Message-ID: Subject: Re: [PATCH v17 0/9] mm / virtio: Provide support for free page reporting To: Andrew Morton Cc: Alexander Duyck , kvm list , David Hildenbrand , "Michael S. Tsirkin" , LKML , linux-mm , Mel Gorman , Yang Zhang , Pankaj Gupta , Konrad Rzeszutek Wilk , Nitesh Narayan Lal , Rik van Riel , Matthew Wilcox , lcapitulino@redhat.com, Dave Hansen , "Wang, Wei W" , Andrea Arcangeli , Paolo Bonzini , Dan Williams , Michal Hocko , Vlastimil Babka , 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 Tue, Feb 11, 2020 at 4:19 PM Andrew Morton wrote: > > On Tue, 11 Feb 2020 15:55:31 -0800 Alexander Duyck wrote: > > > On the host I just have to monitor /proc/meminfo and I can see the > > difference. I get the following results on the host, in the enabled case > > it takes about 30 seconds for it to settle into the final state since I > > only report page a bit at a time: > > Baseline/Applied > > MemTotal: 131963012 kB > > MemFree: 95189740 kB > > > > Enabled: > > MemTotal: 131963012 kB > > MemFree: 126459472 kB > > > > This is what I was referring to with the comment above. I had a test I was > > running back around the first RFC that consisted of bringing up enough VMs > > so that there was a bit of memory overcommit and then having the VMs in > > turn run memhog. As I recall the difference between the two was something > > like a couple minutes to run through all the VMs as the memhog would take > > up to 40+ seconds for one that was having to pull from swap while it took > > only 5 to 7 seconds for the VMs that were all running the page hinting. > > > > I had referenced it here in the RFC: > > https://lore.kernel.org/lkml/20190204181118.12095.38300.stgit@localhost.localdomain/ > > > > I have been verifying the memory has been getting freed but didn't feel > > like the test added much value so I haven't added it to the cover page for > > a while since the time could vary widely and is dependent on things like > > the disk type used for the host swap since my SSD is likely faster than > > spinning rust, but may not be as fast as other SSDs on the market. Since > > the disk speed can play such a huge role I wasn't comfortable posting > > numbers since the benefits could vary so widely. > > OK, thanks. I'll add the patches to the mm pile. The new > mm/page_reporting.c is unreviewed afaict, so I guess you own that for > now ;) I will see what I can do to get some additional review of those patches. There has been some review, but I rewrote that block after suggestions as I had to split it out over several patches to account for the gains from the changes in patches 7 and 8. > It would be very nice to get some feedback from testers asserting "yes, > this really helped my workload" but I understand this sort of testing > is hard to obtain at this stage. Without the QEMU patches applied there isn't much that this patch set can do on its own, so that is another piece I have to work on. Yet another reason to make sure it does no harm if it is not enabled. So far the one that surprised me the most is that somebody from Huawei was working to add device pass-thru support to it already. https://lore.kernel.org/lkml/1578408399-20092-1-git-send-email-weiqi4@huawei.com/ Thanks. - Alex