On Wed, Nov 25, 2020 at 10:40:20PM -0500, Andrea Arcangeli wrote: > On Wed, Nov 25, 2020 at 12:34:41AM -0500, Andrea Arcangeli wrote: > > Summary: both old code (missing PG_reserved) and the current code > (leaving the page struct uninitialized and with wrong nodeid/nid) look > wrong. > > Overall this brings more questions: > > - why memblock.reserved exists and isn't automatically calculated as > inversion of memblock.memory? (or if you prefer: why is the above > call to memblock_reserve needed to initialize the memory holes?) memblock.reserved represents memory areas that were allocated before page allocator is up. This could be memory reported by firmware as resrved, kernel image, initrd, and any memory kernel allocates before page allocator is ready. > - why there's no initialization of the memblock.reserved regions given > they exists, was it just an oversight? (this one is fixed by Mike's > patch, although I wish it was possible to drop the function > memblock_reserve instead) It was an oversight when I posted 73a6e474cb376921a311786652782155eac2fdf0. I overlooked the fact that x86 does not consider memory allocated by firmware as memory and only parts of it are considred reserved. > - what can we do instead of setting the uninitialized nodeid/nid to > 0,0 and to reliably detect at boot if some page structure within > zones (but ideally also outside the zone boundary for any pfn where > pfn_valid returns true) is left uninitialized, as it is happening > currently on the e820 type 20 range? I think that we need to fix the e820 and memblock interaction at the first place. The "non-RAM" holes reported as various types other than E820_TYPE_RAM are actually seem to be "RAM that firmware grabbed for itself", so they should be seen by the system as such, like in all other architectures. For the regions that cannot be mapped, like those on HPE UV (was it SGI?) systems, we have MEMBLOCK_NOMAP exactly for that purpose. Once this is done, we can straihgten logic around memmap intialization in page_alloc, and I feel it will get simpler that today in the end. > Thanks, > Andrea -- Sincerely yours, Mike.
