Hi tj, On 06/18/2013 10:03 AM, Tejun Heo wrote: ......
So, can you please explain why you're doing the above? What are you trying to achieve in the end and why is this the best approach? This is all for memory hotplug, right?
Yes, this is all for memory hotplug. [why] At early boot time (before parsing SRAT), memblock will allocate memory for kernel to use. But the memory could be hotpluggable memory because at such an early time, we don't know which memory is hotpluggable. This will cause hotpluggable memory un-hotpluggable. What we are trying to do is to prevent memblock from allocating hotpluggable memory. [approach] Parse SRAT earlier before memblock starts to work, because there is a bit in SRAT specifying which memory is hotpluggable. I'm not saying this is the best approach. I can also see that this patch-set touches a lot of boot code. But i think parsing SRAT earlier is reasonable because this is the only way for now to know which memory is hotpluggable from firmware.
I can understand the part where you're move NUMA discovery before initializations which will get allocated permanent addresses in the wrong nodes, but trying to do the same with memblock itself is making the code extremely fragile. It's nasty because there's nothing apparent which seems to necessitate such ordering. The ordering looks rather arbitrary but changing the orders will subtly break memory hotplug support, which is a really bad way to structure the code. Can't you just move memblock arrays after NUMA init is complete? That'd be a lot simpler and way more robust than the proposed changes, no?
Sorry, I don't quite understand the approach you are suggesting. If we move memblock arrays, we need to update all the pointers pointing to the moved memory. How can we do this ? Thanks. :) -- 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>