From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Harry Yoo <harry.yoo@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org, Will Deacon <will@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Arnd Bergmann <arnd@arndb.de>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>, Rik van Riel <riel@surriel.com>,
Laurence Oberman <loberman@redhat.com>,
Prakash Sangappa <prakash.sangappa@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Liu Shixin <liushixin2@huawei.com>
Subject: Re: [PATCH v2 2/4] mm/hugetlb: fix two comments related to huge_pmd_unshare()
Date: Fri, 19 Dec 2025 07:11:00 +0100 [thread overview]
Message-ID: <506fef86-5c3b-490e-94f9-2eb6c9c47834@kernel.org> (raw)
In-Reply-To: <aUTYE9fHf5Fq3eHa@hyeyoo>
On 12/19/25 05:44, Harry Yoo wrote:
> On Fri, Dec 12, 2025 at 08:10:17AM +0100, David Hildenbrand (Red Hat) wrote:
>> Ever since we stopped using the page count to detect shared PMD
>> page tables, these comments are outdated.
>>
>> The only reason we have to flush the TLB early is because once we drop
>> the i_mmap_rwsem, the previously shared page table could get freed (to
>> then get reallocated and used for other purpose). So we really have to
>> flush the TLB before that could happen.
>>
>> So let's simplify the comments a bit.
>>
>> The "If we unshared PMDs, the TLB flush was not recorded in mmu_gather."
>> part introduced as in commit a4a118f2eead ("hugetlbfs: flush TLBs
>> correctly after huge_pmd_unshare") was confusing: sure it is recorded
>> in the mmu_gather, otherwise tlb_flush_mmu_tlbonly() wouldn't do
>> anything. So let's drop that comment while at it as well.
>>
>> We'll centralize these comments in a single helper as we rework the code
>> next.
>>
>> Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count")
>> Reviewed-by: Rik van Riel <riel@surriel.com>
>> Tested-by: Laurence Oberman <loberman@redhat.com>
>> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Acked-by: Oscar Salvador <osalvador@suse.de>
>> Cc: Liu Shixin <liushixin2@huawei.com>
>> Signed-off-by: David Hildenbrand (Red Hat) <david@kernel.org>
>> ---
>
> Looks good to me,
> Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
>
> with a question below.
Hi Harry,
thanks for the review!
>
>> mm/hugetlb.c | 24 ++++++++----------------
>> 1 file changed, 8 insertions(+), 16 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 51273baec9e5d..3c77cdef12a32 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -5304,17 +5304,10 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
>> tlb_end_vma(tlb, vma);
>>
>> /*
>> - * If we unshared PMDs, the TLB flush was not recorded in mmu_gather. We
>> - * could defer the flush until now, since by holding i_mmap_rwsem we
>> - * guaranteed that the last reference would not be dropped. But we must
>> - * do the flushing before we return, as otherwise i_mmap_rwsem will be
>> - * dropped and the last reference to the shared PMDs page might be
>> - * dropped as well.
>> - *
>> - * In theory we could defer the freeing of the PMD pages as well, but
>> - * huge_pmd_unshare() relies on the exact page_count for the PMD page to
>> - * detect sharing, so we cannot defer the release of the page either.
>> - * Instead, do flush now.
>
> Does this mean we can now try defer-freeing of these page tables,
> and if so, would it be worth it?
There is one very tricky thing:
Whoever is the last owner of a (previously) shared page table must unmap
any contained pages (adjust mapcount/ref, sync a/d bit, ...). So it's
not just a matter of deferring the freeing, because these page tables
will still contain content.
I first tried to never allow for reuse of shared page tables, but
precisely that resulted in most headakes.
So I don't see an easy way to achieve that (and I'm also not sure if we
want to add any further complexity to this).
--
Cheers
David
next prev parent reply other threads:[~2025-12-19 6:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 7:10 [PATCH v2 0/4] mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather) David Hildenbrand (Red Hat)
2025-12-12 7:10 ` [PATCH v2 1/4] mm/hugetlb: fix hugetlb_pmd_shared() David Hildenbrand (Red Hat)
2025-12-12 7:10 ` [PATCH v2 2/4] mm/hugetlb: fix two comments related to huge_pmd_unshare() David Hildenbrand (Red Hat)
2025-12-19 4:44 ` Harry Yoo
2025-12-19 6:11 ` David Hildenbrand (Red Hat) [this message]
2025-12-19 11:20 ` Harry Yoo
2025-12-19 14:13 ` David Hildenbrand (Red Hat)
2025-12-19 21:37 ` Nadav Amit
2025-12-21 9:26 ` David Hildenbrand (Red Hat)
2025-12-12 7:10 ` [PATCH v2 3/4] mm/rmap: " David Hildenbrand (Red Hat)
2025-12-12 7:10 ` [PATCH v2 4/4] mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather David Hildenbrand (Red Hat)
2025-12-16 10:47 ` Lorenzo Stoakes
2025-12-19 12:37 ` Harry Yoo
2025-12-19 13:52 ` David Hildenbrand (Red Hat)
2025-12-19 13:59 ` David Hildenbrand (Red Hat)
2025-12-21 12:24 ` David Hildenbrand (Red Hat)
2025-12-22 2:09 ` Harry Yoo
2025-12-22 10:10 ` David Hildenbrand (Red Hat)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=506fef86-5c3b-490e-94f9-2eb6c9c47834@kernel.org \
--to=david@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=arnd@arndb.de \
--cc=harry.yoo@oracle.com \
--cc=jannh@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liushixin2@huawei.com \
--cc=loberman@redhat.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=muchun.song@linux.dev \
--cc=nadav.amit@gmail.com \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=prakash.sangappa@oracle.com \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox