[PATCH] fadump: Register the memory reserved by fadump
mpe at ellerman.id.au
Fri Aug 5 19:25:03 AEST 2016
Srikar Dronamraju <srikar at linux.vnet.ibm.com> writes:
> * Michael Ellerman <mpe at ellerman.id.au> [2016-08-05 17:07:01]:
>> Srikar Dronamraju <srikar at linux.vnet.ibm.com> writes:
>> > Fadump kernel reserves large chunks of memory even before the pages are
>> > initialized. This could mean memory that corresponds to several nodes might
>> > fall in memblock reserved regions.
>> > Register the memory reserved by fadump, so that the cache sizes are
>> > calculated based on the free memory (i.e Total memory - reserved
>> > memory).
>> The memory is reserved, with memblock_reserve(). Why is that not sufficient?
> Because at page initialization time, the kernel doesnt know how many
> pages are reserved.
The kernel does know, the fadump code that does the memblock reserve
runs before start_kernel(). AFAIK all calls to alloc_large_system_hash()
are after that.
So the problem seems to be just that alloc_large_system_hash() doesn't
know about reserved memory.
> One way to do that would be to walk through the different memory
> reserved blocks and calculate the size. But Mel feels thats an
> overhead (from his reply to the other thread) esp for just one use
OK. I think you're referring to this:
If fadump is reserving memory and alloc_large_system_hash(HASH_EARLY)
does not know about then then would an arch-specific callback for
arch_reserved_kernel_pages() be more appropriate?
That approach would limit the impact to ppc64 and would be less costly than
doing a memblock walk instead of using nr_kernel_pages for everyone else.
That sounds more robust to me than this solution.
More information about the Linuxppc-dev