[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8e566857-d552-86f4-cbbb-5eed9de6acca@redhat.com>
Date: Thu, 1 Sep 2022 18:30:04 +0200
From: David Hildenbrand <david@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Sasha Levin <sasha.levin@...cle.com>,
"Aneesh Kumar K . V" <aneesh.kumar@...ux.vnet.ibm.com>,
Vlastimil Babka <vbabka@...e.cz>,
Jerome Marchand <jmarchan@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Hugh Dickins <hughd@...gle.com>,
John Hubbard <jhubbard@...dia.com>,
Peter Xu <peterx@...hat.com>, Yang Shi <shy828301@...il.com>
Subject: Re: [PATCH v1] mm/gup: adjust stale comment for RCU GUP-fast
On 01.09.22 18:12, Jason Gunthorpe wrote:
> On Thu, Sep 01, 2022 at 09:21:19AM +0200, David Hildenbrand wrote:
>> commit 4b471e8898c3 ("mm, thp: remove infrastructure for handling splitting
>> PMDs") didn't remove all details about the THP split requirements for
>> RCU GUP-fast.
>>
>> IPI broeadcasts on THP split are no longer required.
>>
>> Cc: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
>> Cc: Sasha Levin <sasha.levin@...cle.com>
>> Cc: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
>> Cc: Vlastimil Babka <vbabka@...e.cz>
>> Cc: Jerome Marchand <jmarchan@...hat.com>
>> Cc: Andrea Arcangeli <aarcange@...hat.com>
>> Cc: Hugh Dickins <hughd@...gle.com>
>> Cc: Jason Gunthorpe <jgg@...dia.com>
>> Cc: John Hubbard <jhubbard@...dia.com>
>> Cc: Peter Xu <peterx@...hat.com>
>> Cc: Yang Shi <shy828301@...il.com>
>> Signed-off-by: David Hildenbrand <david@...hat.com>
>> ---
>> mm/gup.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> The comment a bit above seems to need touching to:
>
> * protected from page table pages being freed from under it, and should
> * block any THP splits.
Ah right. Will drop it as well -- thanks!
>
> What is the current situation for THP splits anyhow? Is there are
> comment in the fast pmd code explaining it?
Not aware of a comment, I think it just works naturally by always
re-routing references taken on tail pages to the head page refcount.
Before that, we had "Tail page refcounting", which -- as I understand --
was a mess.
ddc58f27f9eee9117219936f77e90ad5b2e00e96 contains some comments.
>
> But this seems OK too
>
> Reviewed-by: Jason Gunthorpe <jgg@...dia.com>
>
> Jason
>
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists