On Wed, May 26, 2021 at 02:04:26PM +0100, Catalin Marinas wrote: > On Wed, May 26, 2021 at 12:09:14PM +0000, Qian Cai (QUIC) wrote: > > [ 0.000000] Early memory node ranges > > [ 0.000000] node 0: [mem 0x0000000090000000-0x0000000091ffffff] > > Maybe de-selecting HOLES_IN_ZONE is not correct for arm64 in all > circumstances. In a configuration with 64K pages, MAX_ORDER is 14, > MAX_ORDER_NR_PAGES is 8192, so a 2^29 address range. However, the above > range starts on 2^28 boundary. > > SECTION_SIZE_BITS is 29 in this configuration but the corresponding > mem_map[] in the first half of the first section is probably not marked > as reserved as we'd do for NOMAP. We do initialize (or at least we should) the first of the first section in page_alloc::init_unavailable_range() so the range [0x8000000 - 0x9000000] will have struct pages marked as reserved. I think it should be fine to de-select HOLES_IN_ZONE as long as MAX_ORDER chunk does not exceed a section because we do have memory map there in such case and HOLES_IN_ZONE along with pfn_valid_within() protected against access to non-existing memory map entries. We still have an issue with memory map initialization, and probably I've missed something in decoupling of "do we have memory there" from pfn_valid(). -- Sincerely yours, Mike.
