Hello, Tang. On Tue, Aug 13, 2013 at 12:29:51AM +0800, Tang Chen wrote: > As you said, we can ensure at least one node to be unhotplug. Then the > kernel will boot anyway. Just like CPU0. But we have the chance to lose > one movable node. > > The best way is firmware and software corporate together. SRAT provides > several movable node and enough non-movable memory for the kernel to > boot. The hotplug users only use movable node. I'm really lost on this conversation and have no idea what you're arguing. My point was simple - let the kernel do its best during boot and report the result to userland on what nodes are hotpluggable or not. Can you please elaborate what your point is from the ground up? Unfortunately, I currently have no idea what you're saying. > But, different users have different ways to use memory hotplug. > > Hotswaping any particular chunk of memory is the goal we will reach > finally. But it is on specific hardware. In most current machines, we > can use movable node to manage resource in node unit. > > And also, without this movablenode boot option, the MOVABLE_NODE > functionality, which is already in the kernel, will not be able to > work. All nodes has kernel memory means no movable node. > > So, how about this: Just like MOVABLE_NODE functionality, introduce > a new config option. When we have better solutions for memory hotplug, > we shutoff or remove the config and related code. > > For now, at least make movable node work. We are talking completely past each other. I'll just try to clarify what I was saying. Can you please do the same? Let's re-sync on the discussion. * Adding an option to tell the kernel to try to stay away from hotpluggable nodes is fine. I have no problem with that at all. * The patchsets upto this point have been somehow trying to reorder operations shomehow such that *no* memory allocation happens before memblock is populated with hotplug information. * However, we already *know* that the memory the kernel image is occupying won't be removeable. It's highly likely that the amount of memory allocation before NUMA / hotplug information is fully populated is pretty small. Also, it's highly likely that small amount of memory right after the kernel image is contained in the same NUMA node, so if we allocate memory close to the kernel image, it's likely that we don't contaminate hotpluggable node. We're talking about few megs at most right after the kernel image. I can't see how that would make any noticeable difference. * Once hotplug information is available, allocation can happen as usual and the kernel can report the nodes which are actually hotpluggable - marked as hotpluggable by the firmware && didn't get contaminated during early alloc && didn't get overflow allocations afterwards. Note that we need such mechanism no matter what as the kernel image can be loaded into hotpluggable nodes and reporting that to userland is the only thing the kernel can do for cases like that short of denying memory unplug on such nodes. The whole thing would be a lot simpler and generic. It doesn't even have to care about which mechanism is being used to acquire all those information. What am I missing here? Thanks. -- tejun -- 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>