On Tue, Feb 26, 2013 at 11:11 PM, Tang Chen <tangc...@cn.fujitsu.com> wrote: > On 02/27/2013 02:54 PM, Yinghai Lu wrote: >> >> Those patches are tangled together. > > > No, they are not. > > The following commits supports "movablemem_map=nn[KMG]@ss[KMG]". > > commit fb06bc8e5f42f38c011de0e59481f464a82380f6 > page_alloc: bootmem limit with movablecore_map > commit 42f47e27e761fee07da69e04612ec7dd0d490edd > page_alloc: make movablemem_map have higher priority > commit 6981ec31146cf19454c55c130625f6cee89aab95 > page_alloc: introduce zone_movable_limit[] to keep movable limit for nodes > commit 34b71f1e04fcba578e719e675b4882eeeb2a1f6f > page_alloc: add movable_memmap kernel parameter > commit 4d59a75125d5a4717e57e9fc62c64b3d346e603e > x86: get pg_data_t's memory from other node > > And the following supports "movablemem_map=srat". > > commit f7210e6c4ac795694106c1c5307134d3fc233e88 > mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to protect > movablecore_map in memblock_overlaps_region(). > commit 01a178a94e8eaec351b29ee49fbb3d1c124cb7fb > acpi, memory-hotplug: support getting hotplug info from SRAT > commit 27168d38fa209073219abedbe6a9de7ba9acbfad > acpi, memory-hotplug: extend movablemem_map ranges to the end of node > commit e8d1955258091e4c92d5a975ebd7fd8a98f5d30f > acpi, memory-hotplug: parse SRAT before memblock is ready
those four can be reverted cleanly? > >> >> Also it looks funny to ask user to specify mem range in boot command >> line to enable mem hotplug. > > > Well, I think sometimes users don't like the SRAT memory style, and want to > increase or reduce hot-pluggable memory by themselves. And also, it is > useful > for debuging firmware bugs. > > I agree that "movablemem_map=srat" functionality need more work to improve. > Can we not revert it, and improve it during 3.9rc ? I think during rc time, > at least we can fix the problems brought by early_parse_srat(). looks like acpi_override can not be fixed. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
