On Thu, Aug 30, 2018 at 11:58:19AM -0400, Mikulas Patocka wrote: > On Wed, 29 Aug 2018, James Morse wrote: > > HOLES_IN_ZONE is similar, if some memory is smaller than MAX_ORDER_NR_PAGES, > > possibly due to nomap holes. > > > > 6d526ee26ccd only enabled it for NUMA systems on arm64, because the NUMA code > > was first to fall foul of this, but there is nothing NUMA specific about nomap > > holes within a MAX_ORDER_NR_PAGES region. > > > > I'm convinced arm64 should always enable HOLES_IN_ZONE because nomap pages can > > occur anywhere. I'll post a fix. > > But x86 had the same bug - > https://bugzilla.redhat.com/show_bug.cgi?id=1598462 Yeah, that's not readable and lkml.org is down. Any idea what x86 did? > And x86 fixed it without enabling HOLES_IN_ZONE. On x86, the BIOS can also > reserve any memory range - so you can have arbitrary holes there that are > not predictable when the kernel is compiled. What happens when the BIOS reserves a page on x86? Is it still mapped by the kernel (and therefore has a valid struct page) or is it treated like NOMAP? > Currently HOLES_IN_ZONE is selected only for ia64, mips/octeon - so does > it mean that all the other architectures don't have holes in the memory > map? Possibly. Note also that arm64 already selects HOLES_IN_ZONE if NUMA. > What should be architecture-independent way how to handle the holes? Until firmware is architecture-independent, I think handling this generically is a lost cause. Will
