Re: [PATCH] mm: synchronize with PTE table reclaim for all folio sizes

[David Hildenbrand (Arm)]

On 11/6/26 03:54, Baolin Wang wrote:
> 
> 
> On 11/6/26 10:33 AM, Lance Yang wrote:
>>
>> On Fri, Nov 06, 2026 at 09:57:47AM +0800, Baolin Wang wrote:
>>>
>>>
>>>
>>> Thanks.
>>
>> Cheers!
>>
> 
> .......
> 
>>>
>>> I'm afraid the memory barrier here is subtle. __folio_remove_rmap() is
>>> complex, and in the CONFIG_NO_PAGE_MAPCOUNT branch,
>>> folio_sub_return_large_mapcount() doesn't provide full ordering, so we
>>> may still need smp_wmb().
>>
>> Yeah, agreed for large folios. In the diff above, only order-0 folios
>> use smp_rmb().
>>
>> Note that order-0 folios take the fully ordered atomic_add_negative()
>> branch and skip the CONFIG_NO_PAGE_MAPCOUNT branch entirely.
> 
> Yes.
> 
>> static __always_inline void __folio_remove_rmap(struct folio *folio,
>> 		struct page *page, int nr_pages, struct vm_area_struct *vma,
>> 		enum pgtable_level level)
>> {
>> 	...
>> 	switch (level) {
>> 	case PGTABLE_LEVEL_PTE:
>> 		if (!folio_test_large(folio)) {
>> 			nr = atomic_add_negative(-1, &folio->_mapcount);
>> 			break;
>> 		}
>>
>> 		if (IS_ENABLED(CONFIG_NO_PAGE_MAPCOUNT)) {
>> 			nr = folio_sub_return_large_mapcount(folio, nr_pages, vma);
>> 			...
>> 		}
>> 		...
>> 	}
>> 	...
>> }
>>
>> And large folios still take the PMD lock :D
> 
> IIUC, the memory barrier optimization targets all non-PMD-sized folios 
> (including large folios). That is, for PMD-sized large folios we still 
> use the original PMD lock, while for other non-PMD-sized folios we can 
> use memory barriers to sync.

It would be nice to prototype a patch and document the required memory barriers
and how it is expected to work.

-- 
Cheers,

David