Srikar Dronamraju <[email protected]> writes: > * Michael Ellerman <[email protected]> [2016-08-05 17:07:01]: > >> Srikar Dronamraju <[email protected]> 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
