[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39281a4d-d896-46fd-80a5-8cd547d1625f@bytedance.com>
Date: Tue, 6 Aug 2024 10:40:25 +0800
From: Qi Zheng <zhengqi.arch@...edance.com>
To: David Hildenbrand <david@...hat.com>
Cc: hughd@...gle.com, willy@...radead.org, mgorman@...e.de,
muchun.song@...ux.dev, vbabka@...nel.org, akpm@...ux-foundation.org,
zokeefe@...gle.com, rientjes@...gle.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [RFC PATCH v2 1/7] mm: pgtable: make pte_offset_map_nolock()
return pmdval
Hi David,
On 2024/8/5 22:43, David Hildenbrand wrote:
> On 05.08.24 14:55, Qi Zheng wrote:
>> Make pte_offset_map_nolock() return pmdval so that we can recheck the
>> *pmd once the lock is taken. This is a preparation for freeing empty
>> PTE pages, no functional changes are expected.
>
> Skimming the patches, only patch #4 updates one of the callsites
> (collapse_pte_mapped_thp).
In addition, retract_page_tables() and reclaim_pgtables_pmd_entry()
also used the pmdval returned by pte_offset_map_nolock().
>
> Wouldn't we have to recheck if the PMD val changed in more cases after
> taking the PTL?
>
> If not, would it make sense to have a separate function that returns the
> pmdval and we won't have to update each and every callsite?
pte_offset_map_nolock() had already obtained the pmdval previously, just
hadn't returned it. And updating those callsite is simple, so I think
there may not be a need to add a separate function.
Thanks,
Qi
>
Powered by blists - more mailing lists