[PATCH] fadump: Register the memory reserved by fadump

Michael Ellerman 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
> case.

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 mailing list