[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20231106193315.GB3661273@cmpxchg.org>
Date: Mon, 6 Nov 2023 14:33:15 -0500
From: Johannes Weiner <hannes@...xchg.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Stefan Roesch <shr@...kernel.io>, kernel-team@...com,
akpm@...ux-foundation.org, riel@...riel.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v1] mm: Fix for negative counter: nr_file_hugepages
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().
Powered by blists - more mailing lists