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
