[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e75b509a-bf4f-418c-a921-cf3383fc5929@redhat.com>
Date: Thu, 25 Apr 2024 11:25:11 +0200
From: David Hildenbrand <david@...hat.com>
To: Lance Yang <ioworker0@...il.com>
Cc: ziy@...dia.com, 21cnbao@...il.com, akpm@...ux-foundation.org,
fengwei.yin@...el.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
maskray@...gle.com, mhocko@...e.com, minchan@...nel.org, peterx@...hat.com,
ryan.roberts@....com, shy828301@...il.com, songmuchun@...edance.com,
wangkefeng.wang@...wei.com, willy@...radead.org, xiehuan09@...il.com,
zokeefe@...gle.com
Subject: Re: [PATCH v2 1/1] mm/vmscan: avoid split PMD-mapped THP during
shrink_folio_list()
>> I was wondering if we can better integrate that into the pagewalk below.
>>
>> That is, don't do the TTU_SPLIT_HUGE_PMD immediately. Start the pagewalk
>> first. If we walk a PMD, try to unmap it. Only if that fails, split it.
>
> Nice. Thanks for the suggestion!
> I'll work on integrating it into the pagewalk as you suggested.
>
>>
>> Less working on "vma + address" and instead directly on PMDs.
>
> Yes, some of the work on "vma + address" can be avoided :)
Doing the conditional split while in the pagewalk will be the
interesting bit to sort out (we temporarily have to drop the PTL and
start once again from that now-PTE-mapped page table). But it should be
a reasonable thing to have.
Please let us know if you run into bigger issues with that!
See walk_pmd_range() as an inspiration where we call split_huge_pmd().
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists