[PATCH] fadump: Register the memory reserved by fadump
mgorman at techsingularity.net
Wed Aug 10 17:51:43 AEST 2016
On Wed, Aug 10, 2016 at 04:02:47PM +1000, Michael Ellerman wrote:
> > 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?
I didn't actually check that it tracks the totals. If it does, then the cost
will be negligible in comparison to the total cost of initialising memory.
> > 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.
> > 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.
It would be ideal if the amount of reserved memory that is freed later
in the normal case was estimated. If it's a small percentage of memory
then the difference is unlikely to be detectable and avoids ppc64 being
More information about the Linuxppc-dev