Re: [PATCH v3 20/20] mm: stop maintaining the per-page mapcount of large folios (CONFIG_NO_PAGE_MAPCOUNT)

[Wei Yang]

On Tue, Oct 14, 2025 at 02:59:30PM +0200, David Hildenbrand wrote:
>On 14.10.25 14:23, Wei Yang wrote:
>> On Mon, Mar 03, 2025 at 05:30:13PM +0100, David Hildenbrand wrote:
>> [...]
>> > @@ -1678,6 +1726,22 @@ static __always_inline void __folio_remove_rmap(struct folio *folio,
>> > 		break;
>> > 	case RMAP_LEVEL_PMD:
>> > 	case RMAP_LEVEL_PUD:
>> > +		if (IS_ENABLED(CONFIG_NO_PAGE_MAPCOUNT)) {
>> > +			last = atomic_add_negative(-1, &folio->_entire_mapcount);
>> > +			if (level == RMAP_LEVEL_PMD && last)
>> > +				nr_pmdmapped = folio_large_nr_pages(folio);
>> > +			nr = folio_dec_return_large_mapcount(folio, vma);
>> > +			if (!nr) {
>> > +				/* Now completely unmapped. */
>> > +				nr = folio_large_nr_pages(folio);
>> > +			} else {
>> > +				partially_mapped = last &&
>> > +						   nr < folio_large_nr_pages(folio);
>> 
>> Hi, David
>
>Hi!
>
>> 
>> Do you think this is better to be?
>> 
>> 	partially_mapped = last && nr < nr_pmdmapped;
>
>I see what you mean, it would be similar to the CONFIG_PAGE_MAPCOUNT case
>below.
>
>But probably it could then be
>
>	partially_mapped = nr < nr_pmdmapped;
>
>because nr_pmdmapped is only set when "last = true".
>
>I'm not sure if there is a good reason to change it at this point though.
>Smells like a micro-optimization for PUD, which we probably shouldn't worry
>about.
>
>> 
>> As commit 349994cf61e6 mentioned, we don't support partially mapped PUD-sized
>> folio yet.
>
>We do support partially mapped PUD-sized folios I think, but not anonymous
>PUD-sized folios.
>
>So consequently the partially_mapped variable will never really be used later
>on, because the folio_test_anon() will never hit in the PUD case.
>

Ok, folio_test_anon() takes care of it. We won't add it to defer list by
accident.

>-- 
>Cheers
>
>David / dhildenb

-- 
Wei Yang
Help you, Help me