[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77b1eddf-7c1b-43e9-9352-229998ce3fc7@redhat.com>
Date: Fri, 15 Nov 2024 11:22:31 +0100
From: David Hildenbrand <david@...hat.com>
To: Qi Zheng <zhengqi.arch@...edance.com>
Cc: jannh@...gle.com, hughd@...gle.com, willy@...radead.org,
muchun.song@...ux.dev, vbabka@...nel.org, akpm@...ux-foundation.org,
peterx@...hat.com, mgorman@...e.de, catalin.marinas@....com,
will@...nel.org, dave.hansen@...ux.intel.com, luto@...nel.org,
peterz@...radead.org, x86@...nel.org, lorenzo.stoakes@...cle.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org, zokeefe@...gle.com,
rientjes@...gle.com
Subject: Re: [PATCH v3 4/9] mm: introduce skip_none_ptes()
>>> *nr_skip = nr;
>>>
>>> and then:
>>>
>>> zap_pte_range
>>> --> nr = do_zap_pte_range(tlb, vma, pte, addr, end, details, &skip_nr,
>>> rss, &force_flush, &force_break);
>>> if (can_reclaim_pt) {
>>> none_nr += count_pte_none(pte, nr);
>>> none_nr += nr_skip;
>>> }
>>>
>>> Right?
>>
>> Yes. I did not look closely at the patch that adds the counting of
>
> Got it.
>
>> pte_none though (to digest why it is required :) ).
>
> Because 'none_nr == PTRS_PER_PTE' is used in patch #7 to detect
> empty PTE page.
Okay, so the problem is that "nr" would be "all processed entries" but
there are cases where we "process an entry but not zap it".
What you really only want to know is "was any entry not zapped", which
could be a simple input boolean variable passed into do_zap_pte_range?
Because as soon as any entry was processed but no zapped, you can
immediately give up on reclaiming that table.
>
> Looking forward to your more review feedback on this series.
Thanks for all your hard work on this, I'm only able to make slow
progress because I keep getting distracted by all different kinds of
things :(
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists