[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <424bba1c-d9af-e2a9-0b5a-3a71d525bf30@redhat.com>
Date: Wed, 25 Nov 2020 20:33:01 +0100
From: David Hildenbrand <david@...hat.com>
To: Andrea Arcangeli <aarcange@...hat.com>,
Vlastimil Babka <vbabka@...e.cz>
Cc: Mel Gorman <mgorman@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
Qian Cai <cai@....pw>, Michal Hocko <mhocko@...nel.org>,
linux-kernel@...r.kernel.org, Mike Rapoport <rppt@...ux.ibm.com>,
Baoquan He <bhe@...hat.com>
Subject: Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set
pageblock_skip on reserved pages
On 25.11.20 20:01, Andrea Arcangeli wrote:
> On Wed, Nov 25, 2020 at 01:08:54PM +0100, Vlastimil Babka wrote:
>> Yeah I guess it would be simpler if zoneid/nid was correct for
>> pfn_valid() pfns within a zone's range, even if they are reserved due
>> not not being really usable memory.
>>
>> I don't think we want to introduce CONFIG_HOLES_IN_ZONE to x86. If the
>> chosen solution is to make this to a real hole, the hole should be
>> extended to MAX_ORDER_NR_PAGES aligned boundaries.
>
> The way pfn_valid works it's not possible to render all non-RAM pfn as
> !pfn_valid, CONFIG_HOLES_IN_ZONE would not achieve it 100% either. So
Well, we could do it the arm64 way and provide a custom pfn_valid() and
check memblock for RAM - please don't! :D
> I don't think we can rely on that to eliminate all non-RAM reserved
> pages from the mem_map and avoid having to initialize them in the
> first place. Some could remain as in this case since in the same
> pageblock there's non-RAM followed by RAM and all pfn are valid.
>
>> In any case, compaction code can't fix this with better range checks.
>
> David's correct that it can, by adding enough PageReserved (I'm
> running all systems reproducing this with plenty of PageReserved
> checks in all places to work around it until we do a proper fix).
>
> My problem with that is that 1) it's simply non enforceable at runtime
> that there is not missing PageReserved check and 2) what benefit it
> would provide to leave a wrong zoneid in reserved pages and having to
> add extra PageReserved checks?
See my other mail. If we have a clean way to set *any* memmap (non-RAM,
memory holes at any place) to a proper nid/zid, then we won't need
reserved checks. I raised some cases that need more thought than a
simple "hole in zone".
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists