lkml.org 
[lkml]   [2013]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    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


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