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. > initrd). > 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 special. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>