Srikar Dronamraju <srikar@xxxxxxxxxxxxxxxxxx> writes: > * Michael Ellerman <mpe@xxxxxxxxxxxxxx> [2016-08-05 17:07:01]: > >> Srikar Dronamraju <srikar@xxxxxxxxxxxxxxxxxx> 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. cheers -- 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>