Re: [PATCH 14/21] x86, acpi, numa: Reserve hotpluggable memory at early time.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, Tang.

On Mon, Jul 29, 2013 at 10:12:40AM +0800, Tang Chen wrote:
> So the point is, how to mark the hotpluggable regions and at the
> same time, make
> ACPI and memblock parts independent, right ?

No, not at all.  My point is that the roles need to be divided
clearly.  The firmware (be that ACPI or whatever) knows memory areas
are hotpluggable but it shouldn't be making policy decisions like not
dispending hotpluggable memory through memblock allocator because that
part of logic has *nothing* to do with ACPI.  That is the generic
kernel memory management policy which will apply regardless of what
type of firmware the machine happens to be running on top of.

So, please make ACPI inform memblock of the hotpluggable regions and
implement the allocation policies inside memblock proper.

> So are you saying mark the hotpluggable regions in memblock.memory, but not
> reserve them in memblock.reserved, and make the default allocate
> function avoid
> the hotpluggable regions in memblock.memory ?
>
> This way will be convenient when we put the node_data on local node
> (don't need
> to free regions from memblock.reserved, as you mentioned before), right?

I don't care too much about the specifics and it's likely that you'll
find out which way (flag in memblock.memory, separate region array or
whatever) is better as implementation progresses, but let's please put
things where they belong; otherwise, we end up with weird mess, and,
later on, have to do things like freeing part of reserved hotpluggable
memory for node data from firmware side as you said above, which
basically moves part of memory allocation logic into ACPI, which is
just horrible.

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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]