8. When memory is returned to the memblock or page allocators,
it is _not_ invalidated. In fact, all memory which is freed
need to be valid. If it was marked invalid in the meantime
(e.g. if it the memory was used for DMA buffers), the code
owning the memory needs to validate it again before freeing
it.
The benefit of doing memory validation at allocation time is
that it keeps the exception handler for invalid memory
simple, because no exceptions of this kind are expected under
normal operation.
During early boot I treat unaccepted memory as a usable RAM. It only
requires special treatment on memblock_reserve(), which used for early
memory allocation: unaccepted usable RAM has to be accepted, before
reserving.
For fine-grained accepting/validation tracking I use PageOffline() flags
(it's encoded into mapcount): before adding an unaccepted page to free
list I set the PageOffline() to indicate that the page has to be accepted
before returning from the page allocator. Currently, we never have
PageOffline() set for pages on free lists, so we won't have confusion with
ballooning or memory hotplug.
I was just about to propose something similar. Something like that
sounds like the best approach to me
1. Sync e820 to memblock
2. Sync memblock to memmap
3. Let the page allocator deal with validation once initializing/handing
out memory
PageOffline() does exactly what you want, just be aware that
PageBuddy()+PageOffline() won't be recognized by crash anymore, as it
tests for a single memmap value. Can be fixed with makedumpfile updates
once that applies.
Alternatively, you could use any other page flag that is yet unsued
combined with PageBuddy.
Sure, there might be obstacles, but it certainly sounds like a clean
approach to me.
I try to keep pages accepted in 2M or 4M chunks (pageblock_order or
MAX_ORDER). It is reasonable compromise on speed/latency.
I still debugging the code, but hopefully will get working PoC this week.
[...]
I'm not sure a bitmap is needed. I hope we can use E820 for early
tracking. But let's see if it works.
+1, this smells like an anti-patter. I'm absolutely not in favor of a
bitmap, we have the sparse memory model for a reason.
Also, I am not convinced that kexec/kdump is actually easy to realize
with the bitmap? Who will forward that bitmap? Where will it reside? Who
says it's not corrupted? Just take a look at how we don't even have
access to memmap of the oldkernel in the newkernel -- and have to locate
and decipher it in constantly-to-be-updated user space makedumpfile. Any
time you'd change anything about the bitmap ("hey, let's use larger
chunks", "hey, let's split it up") you'd break the old_kernel <->
new_kernel agreement.
--
Thanks,
David / dhildenb
