Re: [PATCH v1] mm: Fix for negative counter: nr_file_hugepages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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().




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux