* Michael Ellerman <mpe@xxxxxxxxxxxxxx> [2016-08-10 16:57:57]: > Srikar Dronamraju <srikar@xxxxxxxxxxxxxxxxxx> 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 -- 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>