Message ID | 20231106181918.1091043-1-shr@devkernel.io |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp2843215vqu; Mon, 6 Nov 2023 10:19:41 -0800 (PST) X-Google-Smtp-Source: AGHT+IGZju2K/96ficSZOshoyQVrt4JPvIFEEbqwNkvd5V05hrY5xEU6GpwRYLX4jlfGMOMC05bC X-Received: by 2002:a05:6a20:938e:b0:180:7df:76a4 with SMTP id x14-20020a056a20938e00b0018007df76a4mr24617743pzh.45.1699294780980; Mon, 06 Nov 2023 10:19:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699294780; cv=none; d=google.com; s=arc-20160816; b=ayJcR1VemExoMKQQdLrU3ntKQF0YYEK90nLzc5Bj6h2KbX7etWHCdOTsNlpbCEdDcV x3w8kjZVJ+rgytr5NgQgcKKkViBxZVk1Q5+Oj+psduqNYFKUpTp8hB0RzMmrUIcJ00Tn BnakjS9I0dgxVH3HEsyMWu3HzBJYH+vYyHQDJOy7XsIQTwkXZunG7503PbIYdxFs3ac3 61rf4XySEbOrV0oQXQXVWf/PkZhVFvE0vRoG58FIf0nROhw/SgBOWgotiZHxhJh7MdJQ 40PliIV08lCGogIGlOUUFmAuwqxac31B8YzD/3j7SPBTx1yyvp0sCSi64yGcpi0ojU5K v8sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=tznUvWWUhmVDHsO88N8kkhvGkj2v84Ym28VkJnsQfv0=; fh=uk3jM691Xw6iDKhnZS8+oDfSSJp2iEjT2KAdXFaSvP8=; b=l7ersfIerUnTtM6cyLHc3Il+ElFfc1pYLiqT+JteENqXKH0jrE4oBpJtsXoXcoGV80 sk1Pu1uF4MkwIYJwdwS0Bsp4uwrj6GhoihgEGCnRBzn0z0stIvwBYJhVH77XZQUct3j4 +7eke64wnT9TQ2QhBIpQ4wcbsLkDh5Ev7gymJPxEAQPlaAhHcsL+MtDaYwlOTiPvOpwd PeU4FiVeryKRp5px6+CVD4hpTlcnjhot7M18qkeOGyiec27Lr3eo77eIA25JJOwSDmbH /rfa+GL0bDIueYpUozlGgLzqoS2Hq8GGMbUBROH3QQtlM6L7DmOCnMtPC/s8A0UC0Pqd A5vw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id np9-20020a17090b4c4900b0027b123fbe9dsi9301095pjb.156.2023.11.06.10.19.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 10:19:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id B2B9680D6E4D; Mon, 6 Nov 2023 10:19:39 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232369AbjKFSTi (ORCPT <rfc822;lhua1029@gmail.com> + 34 others); Mon, 6 Nov 2023 13:19:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231911AbjKFSTh (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Nov 2023 13:19:37 -0500 Received: from 66-220-144-178.mail-mxout.facebook.com (66-220-144-178.mail-mxout.facebook.com [66.220.144.178]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4388DD69 for <linux-kernel@vger.kernel.org>; Mon, 6 Nov 2023 10:19:34 -0800 (PST) Received: by devbig1114.prn1.facebook.com (Postfix, from userid 425415) id 9D200EE24BAF; Mon, 6 Nov 2023 10:19:19 -0800 (PST) From: Stefan Roesch <shr@devkernel.io> To: kernel-team@fb.com Cc: shr@devkernel.io, akpm@linux-foundation.org, hannes@cmpxchg.org, riel@surriel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v1] mm: Fix for negative counter: nr_file_hugepages Date: Mon, 6 Nov 2023 10:19:18 -0800 Message-Id: <20231106181918.1091043-1-shr@devkernel.io> X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,RDNS_DYNAMIC, SPF_HELO_PASS,SPF_NEUTRAL,TVD_RCVD_IP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 06 Nov 2023 10:19:39 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781839724211996009 X-GMAIL-MSGID: 1781839724211996009 |
Series |
[v1] mm: Fix for negative counter: nr_file_hugepages
|
|
Commit Message
Stefan Roesch
Nov. 6, 2023, 6:19 p.m. UTC
While qualifiying the 6.4 release, the following warning was detected in
messages:
vmstat_refresh: nr_file_hugepages -15664
The warning is caused by the incorrect updating of the NR_FILE_THPS
counter in the function split_huge_page_to_list. The if case is checking
for folio_test_swapbacked, but the else case is missing the check for
folio_test_pmd_mappable. The other functions that manipulate the counter
like __filemap_add_folio and filemap_unaccount_folio have the
corresponding check.
I have a test case, which reproduces the problem. It can be found here:
https://github.com/sroeschus/testcase/blob/main/vmstat_refresh/madv.c
The test case reproduces on an XFS filesystem. Running the same test
case on a BTRFS filesystem does not reproduce the problem.
AFAIK version 6.1 until 6.6 are affected by this problem.
Signed-off-by: Stefan Roesch <shr@devkernel.io>
Co-debugged-by: Johannes Weiner <hannes@cmpxchg.org>
---
mm/huge_memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
base-commit: ffc253263a1375a65fa6c9f62a893e9767fbebfa
Comments
On Mon, 6 Nov 2023 10:19:18 -0800 Stefan Roesch <shr@devkernel.io> wrote: > While qualifiying the 6.4 release, the following warning was detected in > messages: > > vmstat_refresh: nr_file_hugepages -15664 > > The warning is caused by the incorrect updating of the NR_FILE_THPS > counter in the function split_huge_page_to_list. The if case is checking > for folio_test_swapbacked, but the else case is missing the check for > folio_test_pmd_mappable. The other functions that manipulate the counter > like __filemap_add_folio and filemap_unaccount_folio have the > corresponding check. > > I have a test case, which reproduces the problem. It can be found here: > https://github.com/sroeschus/testcase/blob/main/vmstat_refresh/madv.c > > The test case reproduces on an XFS filesystem. Running the same test > case on a BTRFS filesystem does not reproduce the problem. > > AFAIK version 6.1 until 6.6 are affected by this problem. I'm thinking a cc:stable is justified. > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2740,7 +2740,8 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > if (folio_test_swapbacked(folio)) { > __lruvec_stat_mod_folio(folio, NR_SHMEM_THPS, > -nr); > - } else { > + } else if (folio_test_pmd_mappable(folio)) { > + > __lruvec_stat_mod_folio(folio, NR_FILE_THPS, > -nr); > filemap_nr_thps_dec(mapping); > I expect this will backport OK until it hits 3e9a13daa ("huge_memory: convert split_huge_page_to_list() to use a folio") at which point the -stable maintainers might request a reworked version.
On Mon, Nov 06, 2023 at 10:19:18AM -0800, Stefan Roesch wrote: > +++ b/mm/huge_memory.c > @@ -2740,7 +2740,8 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > if (folio_test_swapbacked(folio)) { > __lruvec_stat_mod_folio(folio, NR_SHMEM_THPS, > -nr); > - } else { > + } else if (folio_test_pmd_mappable(folio)) { > + > __lruvec_stat_mod_folio(folio, NR_FILE_THPS, > -nr); > filemap_nr_thps_dec(mapping); Good catch. Two things: 1. No blank line after the 'else if'. 2. We're leaving a bit of a landmine for shmem when it gets support for arbitrary folio sizes. Really all of this should be under a test_pmd_mappable.
On Mon, Nov 06, 2023 at 10:19:18AM -0800, Stefan Roesch wrote: > While qualifiying the 6.4 release, the following warning was detected in > messages: > > vmstat_refresh: nr_file_hugepages -15664 > > The warning is caused by the incorrect updating of the NR_FILE_THPS > counter in the function split_huge_page_to_list. The if case is checking > for folio_test_swapbacked, but the else case is missing the check for > folio_test_pmd_mappable. The other functions that manipulate the counter > like __filemap_add_folio and filemap_unaccount_folio have the > corresponding check. > > I have a test case, which reproduces the problem. It can be found here: > https://github.com/sroeschus/testcase/blob/main/vmstat_refresh/madv.c > > The test case reproduces on an XFS filesystem. Running the same test > case on a BTRFS filesystem does not reproduce the problem. > > AFAIK version 6.1 until 6.6 are affected by this problem. > > Signed-off-by: Stefan Roesch <shr@devkernel.io> > Co-debugged-by: Johannes Weiner <hannes@cmpxchg.org> With the newline fix Willy pointed out, and CC: stable: Acked-by: Johannes Weiner <hannes@cmpxchg.org>
On Mon, Nov 06, 2023 at 06:59:55PM +0000, Matthew Wilcox wrote: > On Mon, Nov 06, 2023 at 10:19:18AM -0800, Stefan Roesch wrote: > > +++ b/mm/huge_memory.c > > @@ -2740,7 +2740,8 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > > if (folio_test_swapbacked(folio)) { > > __lruvec_stat_mod_folio(folio, NR_SHMEM_THPS, > > -nr); > > - } else { > > + } else if (folio_test_pmd_mappable(folio)) { > > + > > __lruvec_stat_mod_folio(folio, NR_FILE_THPS, > > -nr); > > filemap_nr_thps_dec(mapping); > > Good catch. Two things: > > 1. No blank line after the 'else if'. > > 2. We're leaving a bit of a landmine for shmem when it gets support for > arbitrary folio sizes. Really all of this should be under a > test_pmd_mappable. I was wondering if we want to keep NR_FILE_THPS permanently for original flavor 512 basepage THPs, or whether they should account large folios as well? Same for NR_ANON_THPS and NR_SHMEM_THPS. If so, then I agree this should all be conditional on pmdmapped. I suppose the same in filemap_unaccount_folio().
diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 064fbd90822b4..ea6bee675c4d3 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2740,7 +2740,8 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) if (folio_test_swapbacked(folio)) { __lruvec_stat_mod_folio(folio, NR_SHMEM_THPS, -nr); - } else { + } else if (folio_test_pmd_mappable(folio)) { + __lruvec_stat_mod_folio(folio, NR_FILE_THPS, -nr); filemap_nr_thps_dec(mapping);