[lkml]   [2013]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH part5 0/7] Arrange hotpluggable memory as ZONE_MOVABLE.
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

* 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?



 \ /
  Last update: 2013-08-12 19:21    [W:0.114 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site