[PATCH] fadump: Register the memory reserved by fadump
Srikar Dronamraju
srikar at linux.vnet.ibm.com
Wed Aug 10 19:21:45 AEST 2016
* Michael Ellerman <mpe at ellerman.id.au> [2016-08-10 16:57:57]:
> 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.
For now memblock structure is only available in mm/memblock.c
Every other access to memblock from outside mm/memblock is through an
api.
> >
> > 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.
>
Okay
--
Thanks and Regards
Srikar Dronamraju
More information about the Linuxppc-dev
mailing list