Re: [PATCH 1/4] mm: mincore: try per-VMA lock firstly and use walk_page_range_vma()

["David Hildenbrand (Arm)" <david@kernel.org>]

On 6/18/26 03:41, Kefeng Wang wrote:
> 
> 
> On 6/17/2026 11:01 PM, David Hildenbrand (Arm) wrote:
>> On 6/17/26 10:26, Kefeng Wang wrote:
>>> The mincore syscall currently takes mmap lock for the entire
>>> duration of the VMA lookup and page table walk. This creates
>>> a global contention point with page faults and other mmap_lock
>>> holders in multi-threaded applications.
>>>
>>> The mincore is a read-only operation that only queries page
>>> residency from a single VMA, making it an ideal candidate for
>>> per-VMA locking, so try per-vma lock firstly and use the
>>> walk_page_range_vma() in do_mincore() to eliminates an unnecessary
>>> find_vma() lookup.
>>>
>>> Unlike walk_page_range(), walk_page_range_vma() does not call
>>> walk_page_test(), which handles VM_PFNMAP by invoking ->pte_hole()
>>> to skip the page table walk. Without this check, PFNMAP PTEs
>>> would be treated as present by mincore_pte_range(), changing
>>> the returned residency status. Handle VM_PFNMAP explicitly in
>>> do_mincore() to preserve the original behavior.
>>>
>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>>> ---
>>
>> I think you should first add a patch that converts do_mincore() to just use
>> walk_page_range_vma() -- which is what your patch series "mm: convert to
>> walk_page_range_vma() to eliminate find_vma()" wants to achieve.
>>
>> Which would already be an improvement :)
>>
> 
> Are you suggesting that the per-vma optimization should be separated
> out? This change is not too big, and I am fine with either, which
> method do you prefer?

Yes, I would split the "use "walk_page_range_vma" from "use per-VMA lock", even
though the first patch would be rather small.

-- 
Cheers,

David