[PATCH] fadump: Register the memory reserved by fadump

Michael Ellerman mpe at ellerman.id.au
Wed Aug 10 16:57:57 AEST 2016

Srikar Dronamraju <srikar at linux.vnet.ibm.com> writes:

>> > Conceptually it would be cleaner, if expensive, to calculate the real
>> > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve
>> > and nr_kernel_pages entirely.
>> Why is it expensive? memblock tracks the totals for all memory and
>> reserved memory AFAIK, so it should just be a case of subtracting one
>> from the other?
> Are you suggesting that we use something like
> memblock_phys_mem_size() but one which returns
> memblock.reserved.total_size ? Maybe a new function like
> memblock_reserved_mem_size()?

Yeah, something like that. I'm not sure if it actually needs a function,
AFAIK you can just look at the structure directly.

>> > Unfortuantely, aside from the calculation,
>> > there is a potential cost due to a smaller hash table that affects everyone,
>> > not just ppc64.
>> Yeah OK. We could make it an arch hook, or controlled by a CONFIG.
> If its based on memblock.reserved.total_size, then should it be arch
> specific?

Yes I think so. Otherwise you have to test it on every architecture :)

>> > However, if the hash table is meant to be sized on the
>> > number of available pages then it really should be based on that and not
>> > just a made-up number.
>> Yeah that seems to make sense.
>> The one complication I think is that we may have memory that's marked
>> reserved in memblock, but is later freed to the page allocator (eg.
>> initrd).
> Yes, this is a possibility, for example lets say we want fadump to
> continue to run instead of rebooting to a new kernel as it does today.

But that's a bad idea and no one should ever do it.

For starters all your caches will be undersized, and anything that is
allocated per-node early in boot will not be allocated on the nodes
which were reserved, so the system's performance will potentially differ
from a normal boot in weird and unpredictable ways.


More information about the Linuxppc-dev mailing list