From: Tang Chen <tangchen@cn.fujitsu.com> To: Tejun Heo <tj@kernel.org> Cc: tglx@linutronix.de, mingo@elte.hu, hpa@zytor.com, akpm@linux-foundation.org, trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com, wency@cn.fujitsu.com, laijs@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com, mgorman@suse.de, minchan@kernel.org, mina86@mina86.com, gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com, lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com, prarit@redhat.com, zhangyanfei@cn.fujitsu.com, yanghy@cn.fujitsu.com, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH 14/21] x86, acpi, numa: Reserve hotpluggable memory at early time. Date: Mon, 29 Jul 2013 10:12:40 +0800 [thread overview] Message-ID: <51F5CF98.1080101@cn.fujitsu.com> (raw) In-Reply-To: <20130726102609.GB30786@mtj.dyndns.org> On 07/26/2013 06:26 PM, Tejun Heo wrote: > On Fri, Jul 26, 2013 at 11:45:36AM +0800, Tang Chen wrote: >> I just don't want to any new variables to store the hotpluggable regions. >> But without a new shared variable, it seems difficult to achieve the goal >> you said below. > > Why can't it be done with the .flags field that was added anyway? I'm sorry but I'm a little misunderstanding here. There are some more things I want to confirm, thanks for your patient. :) By "the goal" above, I mean making ACPI and memblock parts more independent from each other. I think in this patch-set, I called memblock_reserve() which made these two parts interactive. So the point is, how to mark the hotpluggable regions and at the same time, make ACPI and memblock parts independent, right ? But, please see below. > >> So how about this. >> 1. Introduce a new global list used to store hotpluggable regions. >> 2. On acpi side, find and fulfill the list. >> 3. On memblock side, make the default allocation function stay away from >> these regions. > > I was thinking more along the line of > > 1. Mark hotpluggable regions with a flag in memblock. > 2. On ACPI side, find and mark hotpluggable regions. But marking hotpluggable regions on ACPI side will also make ACPI and memblock parts more interactive. In this patch-set, I just called memblock_reserve() directly on ACPI side. I think marking hotpluggable regions on ACPI side is much the same as reserving the regions. I will just call something like memblock_mark_flags() to mark the regions. The only difference will be a different memblock_xxx() function call, right ? In the last mail, I suggested a global array. So both sides will just use the array, and it seems to be independent. But I think the global array and the flags in memblock are redundant. They are for the same goal. Actually I want to use flags. I think it is also useful when we try to put thins on local node, such as node_data. So, is it OK to mark the hotpluggable regions on ACPI side ? > 3. Make memblock avoid giving out hotpluggable regions for normal > allocations. This step3 is different from this patch-set. I reserved hotpluggable regions in memblock.reserved. 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? Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com> To: Tejun Heo <tj@kernel.org> Cc: tglx@linutronix.de, mingo@elte.hu, hpa@zytor.com, akpm@linux-foundation.org, trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com, wency@cn.fujitsu.com, laijs@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com, mgorman@suse.de, minchan@kernel.org, mina86@mina86.com, gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com, lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com, prarit@redhat.com, zhangyanfei@cn.fujitsu.com, yanghy@cn.fujitsu.com, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH 14/21] x86, acpi, numa: Reserve hotpluggable memory at early time. Date: Mon, 29 Jul 2013 10:12:40 +0800 [thread overview] Message-ID: <51F5CF98.1080101@cn.fujitsu.com> (raw) In-Reply-To: <20130726102609.GB30786@mtj.dyndns.org> On 07/26/2013 06:26 PM, Tejun Heo wrote: > On Fri, Jul 26, 2013 at 11:45:36AM +0800, Tang Chen wrote: >> I just don't want to any new variables to store the hotpluggable regions. >> But without a new shared variable, it seems difficult to achieve the goal >> you said below. > > Why can't it be done with the .flags field that was added anyway? I'm sorry but I'm a little misunderstanding here. There are some more things I want to confirm, thanks for your patient. :) By "the goal" above, I mean making ACPI and memblock parts more independent from each other. I think in this patch-set, I called memblock_reserve() which made these two parts interactive. So the point is, how to mark the hotpluggable regions and at the same time, make ACPI and memblock parts independent, right ? But, please see below. > >> So how about this. >> 1. Introduce a new global list used to store hotpluggable regions. >> 2. On acpi side, find and fulfill the list. >> 3. On memblock side, make the default allocation function stay away from >> these regions. > > I was thinking more along the line of > > 1. Mark hotpluggable regions with a flag in memblock. > 2. On ACPI side, find and mark hotpluggable regions. But marking hotpluggable regions on ACPI side will also make ACPI and memblock parts more interactive. In this patch-set, I just called memblock_reserve() directly on ACPI side. I think marking hotpluggable regions on ACPI side is much the same as reserving the regions. I will just call something like memblock_mark_flags() to mark the regions. The only difference will be a different memblock_xxx() function call, right ? In the last mail, I suggested a global array. So both sides will just use the array, and it seems to be independent. But I think the global array and the flags in memblock are redundant. They are for the same goal. Actually I want to use flags. I think it is also useful when we try to put thins on local node, such as node_data. So, is it OK to mark the hotpluggable regions on ACPI side ? > 3. Make memblock avoid giving out hotpluggable regions for normal > allocations. This step3 is different from this patch-set. I reserved hotpluggable regions in memblock.reserved. 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? Thanks.
next prev parent reply other threads:[~2013-07-29 2:12 UTC|newest] Thread overview: 152+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-19 7:59 [PATCH 00/21] Arrange hotpluggable memory as ZONE_MOVABLE Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-19 7:59 ` [PATCH 01/21] acpi: Print Hot-Pluggable Field in SRAT Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 18:48 ` Tejun Heo 2013-07-23 18:48 ` Tejun Heo 2013-07-23 19:15 ` Joe Perches 2013-07-23 19:15 ` Joe Perches 2013-07-23 19:20 ` Tejun Heo 2013-07-23 19:20 ` Tejun Heo 2013-07-23 19:26 ` Joe Perches 2013-07-23 19:26 ` Joe Perches 2013-07-24 1:46 ` Tang Chen 2013-07-24 1:46 ` Tang Chen 2013-07-19 7:59 ` [PATCH 02/21] memblock, numa: Introduce flag into memblock Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 19:09 ` Tejun Heo 2013-07-23 19:09 ` Tejun Heo 2013-07-24 2:53 ` Tang Chen 2013-07-24 2:53 ` Tang Chen 2013-07-24 15:54 ` Tejun Heo 2013-07-24 15:54 ` Tejun Heo 2013-07-25 6:42 ` Tang Chen 2013-07-25 6:42 ` Tang Chen 2013-07-19 7:59 ` [PATCH 03/21] x86, acpi, numa, mem-hotplug: Introduce MEMBLK_HOTPLUGGABLE to reserve hotpluggable memory Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 19:19 ` Tejun Heo 2013-07-23 19:19 ` Tejun Heo 2013-07-24 2:55 ` Tang Chen 2013-07-24 2:55 ` Tang Chen 2013-07-19 7:59 ` [PATCH 04/21] acpi: Remove "continue" in macro INVALID_TABLE() Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 19:15 ` Tejun Heo 2013-07-23 19:15 ` Tejun Heo 2013-07-19 7:59 ` [PATCH 05/21] acpi: Introduce acpi_invalid_table() to check if a table is invalid Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-19 7:59 ` [PATCH 06/21] x86, acpi: Split acpi_boot_table_init() into two parts Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-19 7:59 ` [PATCH 07/21] x86, acpi: Initialize ACPI root table list earlier Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-19 7:59 ` [PATCH 08/21] x86, acpi: Also initialize signature and length when parsing root table Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 19:45 ` Tejun Heo 2013-07-23 19:45 ` Tejun Heo 2013-07-25 6:50 ` Tang Chen 2013-07-25 6:50 ` Tang Chen 2013-07-19 7:59 ` [PATCH 09/21] x86: Make get_ramdisk_{image|size}() global Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 19:56 ` Tejun Heo 2013-07-23 19:56 ` Tejun Heo 2013-07-24 3:12 ` Tang Chen 2013-07-24 3:12 ` Tang Chen 2013-07-19 7:59 ` [PATCH 10/21] earlycpio.c: Fix the confusing comment of find_cpio_data() Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 20:02 ` Tejun Heo 2013-07-23 20:02 ` Tejun Heo 2013-07-24 3:20 ` Tang Chen 2013-07-24 3:20 ` Tang Chen 2013-07-19 7:59 ` [PATCH 11/21] x86: get pg_data_t's memory from other node Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 20:09 ` Tejun Heo 2013-07-23 20:09 ` Tejun Heo 2013-07-24 3:52 ` Tang Chen 2013-07-24 3:52 ` Tang Chen 2013-07-24 16:03 ` Tejun Heo 2013-07-24 16:03 ` Tejun Heo 2013-07-19 7:59 ` [PATCH 12/21] x86, acpi: Try to find if SRAT is overrided earlier Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 20:27 ` Tejun Heo 2013-07-23 20:27 ` Tejun Heo 2013-07-24 6:57 ` Tang Chen 2013-07-24 6:57 ` Tang Chen 2013-07-19 7:59 ` [PATCH 13/21] x86, acpi: Try to find SRAT in firmware earlier Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 20:49 ` Tejun Heo 2013-07-23 20:49 ` Tejun Heo 2013-07-24 10:12 ` Tang Chen 2013-07-24 10:12 ` Tang Chen 2013-07-24 15:55 ` Tejun Heo 2013-07-24 15:55 ` Tejun Heo 2013-07-23 23:26 ` Cody P Schafer 2013-07-23 23:26 ` Cody P Schafer 2013-07-24 10:16 ` Tang Chen 2013-07-24 10:16 ` Tang Chen 2013-07-19 7:59 ` [PATCH 14/21] x86, acpi, numa: Reserve hotpluggable memory at early time Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 20:55 ` Tejun Heo 2013-07-23 20:55 ` Tejun Heo 2013-07-23 21:32 ` Tejun Heo 2013-07-23 21:32 ` Tejun Heo 2013-07-25 2:13 ` Tang Chen 2013-07-25 2:13 ` Tang Chen 2013-07-25 15:17 ` Tejun Heo 2013-07-25 15:17 ` Tejun Heo 2013-07-26 3:45 ` Tang Chen 2013-07-26 3:45 ` Tang Chen 2013-07-26 10:26 ` Tejun Heo 2013-07-26 10:26 ` Tejun Heo 2013-07-26 10:27 ` Tejun Heo 2013-07-26 10:27 ` Tejun Heo 2013-07-29 2:12 ` Tang Chen [this message] 2013-07-29 2:12 ` Tang Chen 2013-07-29 17:10 ` Tejun Heo 2013-07-29 17:10 ` Tejun Heo 2013-07-19 7:59 ` [PATCH 15/21] x86, acpi, numa: Don't reserve memory on nodes the kernel resides in Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 20:59 ` Tejun Heo 2013-07-23 20:59 ` Tejun Heo 2013-07-25 2:34 ` Tang Chen 2013-07-25 2:34 ` Tang Chen 2013-07-19 7:59 ` [PATCH 16/21] x86, memblock, mem-hotplug: Free hotpluggable memory reserved by memblock Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 21:00 ` Tejun Heo 2013-07-23 21:00 ` Tejun Heo 2013-07-25 2:35 ` Tang Chen 2013-07-25 2:35 ` Tang Chen 2013-07-19 7:59 ` [PATCH 17/21] page_alloc, mem-hotplug: Improve movablecore to {en|dis}able using SRAT Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 21:04 ` Tejun Heo 2013-07-23 21:04 ` Tejun Heo 2013-07-23 21:11 ` Tejun Heo 2013-07-23 21:11 ` Tejun Heo 2013-07-25 3:50 ` Tang Chen 2013-07-25 3:50 ` Tang Chen 2013-07-25 15:09 ` Tejun Heo 2013-07-25 15:09 ` Tejun Heo 2013-07-26 3:58 ` Tang Chen 2013-07-26 3:58 ` Tang Chen 2013-07-19 7:59 ` [PATCH 18/21] x86, numa: Synchronize nid info in memblock.reserve with numa_meminfo Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 21:25 ` Tejun Heo 2013-07-23 21:25 ` Tejun Heo 2013-07-25 4:09 ` Tang Chen 2013-07-25 4:09 ` Tang Chen 2013-07-25 15:05 ` Tejun Heo 2013-07-25 15:05 ` Tejun Heo 2013-07-26 4:00 ` Tang Chen 2013-07-26 4:00 ` Tang Chen 2013-07-19 7:59 ` [PATCH 19/21] x86, numa: Save nid when reserve memory into memblock.reserved[] Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-19 7:59 ` [PATCH 20/21] x86, numa, acpi, memory-hotplug: Make movablecore=acpi have higher priority Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 21:21 ` Tejun Heo 2013-07-23 21:21 ` Tejun Heo 2013-07-19 7:59 ` [PATCH 21/21] doc, page_alloc, acpi, mem-hotplug: Add doc for movablecore=acpi boot option Tang Chen 2013-07-19 7:59 ` Tang Chen 2013-07-23 21:21 ` Tejun Heo 2013-07-23 21:21 ` Tejun Heo 2013-07-25 3:53 ` Tang Chen 2013-07-25 3:53 ` Tang Chen 2013-07-22 2:48 ` [PATCH 00/21] Arrange hotpluggable memory as ZONE_MOVABLE Tang Chen 2013-07-22 2:48 ` Tang Chen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=51F5CF98.1080101@cn.fujitsu.com \ --to=tangchen@cn.fujitsu.com \ --cc=akpm@linux-foundation.org \ --cc=gong.chen@linux.intel.com \ --cc=hpa@zytor.com \ --cc=isimatu.yasuaki@jp.fujitsu.com \ --cc=izumi.taku@jp.fujitsu.com \ --cc=jiang.liu@huawei.com \ --cc=jweiner@redhat.com \ --cc=laijs@cn.fujitsu.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lwoodman@redhat.com \ --cc=mgorman@suse.de \ --cc=mina86@mina86.com \ --cc=minchan@kernel.org \ --cc=mingo@elte.hu \ --cc=prarit@redhat.com \ --cc=riel@redhat.com \ --cc=tglx@linutronix.de \ --cc=tj@kernel.org \ --cc=trenn@suse.de \ --cc=vasilis.liaskovitis@profitbricks.com \ --cc=wency@cn.fujitsu.com \ --cc=x86@kernel.org \ --cc=yanghy@cn.fujitsu.com \ --cc=yinghai@kernel.org \ --cc=zhangyanfei@cn.fujitsu.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.