From patchwork Wed May 26 07:52:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ding Hui X-Patchwork-Id: 12280809 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=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 23D3BC2B9F7 for ; Wed, 26 May 2021 07:53:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AF4A961440 for ; Wed, 26 May 2021 07:53:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AF4A961440 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=sangfor.com.cn Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4D7FB6B0071; Wed, 26 May 2021 03:53:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AE236B0072; Wed, 26 May 2021 03:53:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39D946B0073; Wed, 26 May 2021 03:53:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id 08FF26B0071 for ; Wed, 26 May 2021 03:53:17 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9A9AA98BF for ; Wed, 26 May 2021 07:53:17 +0000 (UTC) X-FDA: 78182616834.29.5CA886E Received: from mail-m121142.qiye.163.com (mail-m121142.qiye.163.com [115.236.121.142]) by imf25.hostedemail.com (Postfix) with SMTP id 41E1C6000250 for ; Wed, 26 May 2021 07:53:08 +0000 (UTC) Received: from localhost.localdomain (unknown [14.154.30.253]) by mail-m121142.qiye.163.com (Hmail) with ESMTPA id D9F0980288; Wed, 26 May 2021 15:53:11 +0800 (CST) From: Ding Hui To: akpm@linux-foundation.org, naoya.horiguchi@nec.com, osalvador@suse.de, david@redhat.com Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ding Hui Subject: [PATCH v3] mm/page_alloc: fix counting of free pages after take off from buddy Date: Wed, 26 May 2021 15:52:47 +0800 Message-Id: <20210526075247.11130-1-dinghui@sangfor.com.cn> X-Mailer: git-send-email 2.17.1 X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSE83V1ktWUFJV1kPCR oVCBIfWUFZQksZQlZMGExLHU4eT0hKSEJVEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVUpKS0 9ISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OFE6UTo*FT8UThkSFStJGCwr GTUwCwNVSlVKTUlJS0pOTkJJT0hPVTMWGhIXVR8SFRwTDhI7CBoVHB0UCVUYFBZVGBVFWVdZEgtZ QVlKT1VKTk9VSEtVSU5IWVdZCAFZQUhLT0k3Bg++ X-HM-Tid: 0a79a7a9c6aab037kuuud9f0980288 X-Rspamd-Queue-Id: 41E1C6000250 Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of dinghui@sangfor.com.cn designates 115.236.121.142 as permitted sender) smtp.mailfrom=dinghui@sangfor.com.cn; dmarc=pass (policy=none) header.from=sangfor.com.cn X-Rspamd-Server: rspam03 X-Stat-Signature: ja9sr51hwps6wdzz95c1fz3imm5t7sha X-HE-Tag: 1622015588-760413 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: Recently we found that there is a lot MemFree left in /proc/meminfo after do a lot of pages soft offline, it's not quite correct. Before Oscar rework soft offline for free pages [1], if we soft offline free pages, these pages are left in buddy with HWPoison flag, and NR_FREE_PAGES is not updated immediately. So the difference between NR_FREE_PAGES and real number of available free pages is also even big at the beginning. However, with the workload running, when we catch HWPoison page in any alloc functions subsequently, we will remove it from buddy, meanwhile update the NR_FREE_PAGES and try again, so the NR_FREE_PAGES will get more and more closer to the real number of available free pages. (regardless of unpoison_memory()) Now, for offline free pages, after a successful call take_page_off_buddy(), the page is no longer belong to buddy allocator, and will not be used any more, but we missed accounting NR_FREE_PAGES in this situation, and there is no chance to be updated later. Do update in take_page_off_buddy() like rmqueue() does, but avoid double counting if some one already set_migratetype_isolate() on the page. [1]: commit 06be6ff3d2ec ("mm,hwpoison: rework soft offline for free pages") Suggested-by: Naoya Horiguchi Signed-off-by: Ding Hui Acked-by: David Hildenbrand Reviewed-by: Oscar Salvador Acked-by: Naoya Horiguchi --- v3: - as Naoya Horiguchi suggested, do update only when is_migrate_isolate(migratetype)) is false - updated patch description v2: - https://lore.kernel.org/linux-mm/20210508035533.23222-1-dinghui@sangfor.com.cn/ - use __mod_zone_freepage_state instead of __mod_zone_page_state mm/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index aaa1655cf682..d1f5de1c1283 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -9158,6 +9158,8 @@ bool take_page_off_buddy(struct page *page) del_page_from_free_list(page_head, zone, page_order); break_down_buddy_pages(zone, page_head, page, 0, page_order, migratetype); + if (!is_migrate_isolate(migratetype)) + __mod_zone_freepage_state(zone, -1, migratetype); ret = true; break; }