Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1179610pxf; Fri, 26 Mar 2021 02:48:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/+1i44Bv4lD+ieYSbTPP0FgTc3WDfzbM9d8+kgU6M7r5FiNnkDkvOuUjCCwqVfOBdPk2m X-Received: by 2002:a05:6402:4314:: with SMTP id m20mr13583145edc.5.1616752131760; Fri, 26 Mar 2021 02:48:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616752131; cv=none; d=google.com; s=arc-20160816; b=BGkPbhhkqaE1t6qvUf7B+5NCClKEdOYOYdeVsWtYm6xrtLRoootsoPJT5drzZ2KihZ ynTOz9Gx+qCQGfvF7wIBkF1KHd9pETe8iwqbEy296D/wq3xNCSPgOYbDYdxvAfbn1oPP B1z0nmL4r57KC36S9SbnIi3vKfLzgbD1K5Ln6iH5SyGl2JQnk7LH81pY+qOzm+AE9qFR g520vzJV86lI+oOW24I69kTqo2HNSHm6SGTcEzT0YX4Pbz/SWSo42hkmFq13Pv0nweeH n7Y5CLwJMFUayYHCLMOIy4SvLB4Xin4lJNZmyaxmfZsWgPiA/6UOrYHSw5lhprffQyAp j5JQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=SRGNkVactc/pZokxbr1RCxKfVTiEaTnwpP0z1NjuQwA=; b=USPXGMHrHxslz8htuk9VQKNazuDMfmLZYg5EjZlbu6XeUuFHAHZBSWUQ8yIiUtRdWL AXvPwD5Fx7p08m0Qv8eZQqsOxqVqciqP+RnH4z+9tkWyIRDAVFGv1Y1Pn0ZZ+m4cAXxZ fhSAdgdTPG1oLpNt3LDZkMSTfy9rgGXA4NJkRnQ4GVYM1zYXIQzC+cxrfqpn9+4SH7Go gyG8Rpl++i4ITebXpeL/BbXXHH0ryeHj58u/I4TBfkAm5bCHq4mKqsGsDAW6kvDABXvz nM/2vN8DZNk3GWYrISelvE4kLJ8g1ItxDH2Rm3ntf4O4wrqwNc+Q7RxDXPEUh3TqtY1N R+DQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gb41si6231738ejc.90.2021.03.26.02.48.28; Fri, 26 Mar 2021 02:48:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229898AbhCZJp0 (ORCPT + 99 others); Fri, 26 Mar 2021 05:45:26 -0400 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]:33753 "EHLO out30-42.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229573AbhCZJpC (ORCPT ); Fri, 26 Mar 2021 05:45:02 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01424;MF=xlpang@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0UTMseJh_1616751899; Received: from localhost(mailfrom:xlpang@linux.alibaba.com fp:SMTPD_---0UTMseJh_1616751899) by smtp.aliyun-inc.com(127.0.0.1); Fri, 26 Mar 2021 17:44:59 +0800 From: Xunlei Pang To: Andrew Morton , Alexander Duyck , Mel Gorman Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Xunlei Pang Subject: [PATCH 3/4] mm/page_reporting: Introduce "page_reporting_factor=" boot parameter Date: Fri, 26 Mar 2021 17:44:57 +0800 Message-Id: <1616751898-58393-4-git-send-email-xlpang@linux.alibaba.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1616751898-58393-1-git-send-email-xlpang@linux.alibaba.com> References: <1616751898-58393-1-git-send-email-xlpang@linux.alibaba.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently the default behaviour(value 100) is to do full report, although we can control it after boot via "page_reporting_factor" sysfs knob, it could still be late because some amount of memory has already been reported before operating this knob. Sometimes we really want it safely off by default and turn it on as needed at runtime, so "page_reporting_factor=" boot parameter is that guarantee and meets different default setting requirements. There's also a real-world problem that I noticed on tiny instances, it always reports some memory at boot stage before application starts and uses up memory which retriggers EPT fault after boot. The following data(right after boot) indicates that 172032KiB pages were unnecessarily reported and refault in: $ cat /sys/kernel/mm/page_reporting/refault_kbytes 172032 $ cat /sys/kernel/mm/page_reporting/reported_kbytes 0 Thus it's reasonable to turn the page reporting off by default and enable it at runtime as needed. Signed-off-by: Xunlei Pang --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ mm/page_reporting.c | 13 +++++++++++++ 2 files changed, 16 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 0454572..46e296c 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3524,6 +3524,9 @@ off: turn off poisoning (default) on: turn on poisoning + page_reporting_factor= [KNL] Guest Free Page Reporting percentile. + [0, 100]: 0 - off, not report; 100 - default, full report. + panic= [KNL] Kernel behaviour on panic: delay timeout > 0: seconds before rebooting timeout = 0: wait forever diff --git a/mm/page_reporting.c b/mm/page_reporting.c index 86c6479..6ffedb8 100644 --- a/mm/page_reporting.c +++ b/mm/page_reporting.c @@ -524,3 +524,16 @@ static int __init page_reporting_init(void) } module_init(page_reporting_init); + +static int __init setup_reporting_factor(char *str) +{ + int v; + + if (kstrtoint(str, 10, &v)) + return -EINVAL; + if (v >= 0 && v <= 100) + reporting_factor = v; + + return 0; +} +__setup("page_reporting_factor=", setup_reporting_factor); -- 1.8.3.1