From: Taku Izumi <izumi.taku@jp.fujitsu.com> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: tony.luck@intel.com, qiuxishi@huawei.com, kamezawa.hiroyu@jp.fujitsu.com, mel@csn.ul.ie, dave.hansen@intel.com, matt@codeblueprint.co.uk, Taku Izumi <izumi.taku@jp.fujitsu.com> Subject: [PATCH v3 0/2] mm: Introduce kernelcore=mirror option Date: Wed, 9 Dec 2015 12:18:29 +0900 [thread overview] Message-ID: <1449631109-14756-1-git-send-email-izumi.taku@jp.fujitsu.com> (raw) Xeon E7 v3 based systems supports Address Range Mirroring and UEFI BIOS complied with UEFI spec 2.5 can notify which ranges are mirrored (reliable) via EFI memory map. Now Linux kernel utilize its information and allocates boot time memory from reliable region. My requirement is: - allocate kernel memory from mirrored region - allocate user memory from non-mirrored region In order to meet my requirement, ZONE_MOVABLE is useful. By arranging non-mirrored range into ZONE_MOVABLE, mirrored memory is used for kernel allocations. My idea is to extend existing "kernelcore" option and introduces kernelcore=mirror option. By specifying "mirror" instead of specifying the amount of memory, non-mirrored region will be arranged into ZONE_MOVABLE. Earlier discussions are at: https://lkml.org/lkml/2015/10/9/24 https://lkml.org/lkml/2015/10/15/9 https://lkml.org/lkml/2015/11/27/18 For example, suppose 2-nodes system with the following memory range: node 0 [mem 0x0000000000001000-0x000000109fffffff] node 1 [mem 0x00000010a0000000-0x000000209fffffff] and the following ranges are marked as reliable (mirrored): [0x0000000000000000-0x0000000100000000] [0x0000000100000000-0x0000000180000000] [0x0000000800000000-0x0000000880000000] [0x00000010a0000000-0x0000001120000000] [0x00000017a0000000-0x0000001820000000] If you specify kernelcore=mirror, ZONE_NORMAL and ZONE_MOVABLE are arranged like bellow: - node 0: ZONE_NORMAL : [0x0000000100000000-0x00000010a0000000] ZONE_MOVABLE: [0x0000000180000000-0x00000010a0000000] - node 1: ZONE_NORMAL : [0x00000010a0000000-0x00000020a0000000] ZONE_MOVABLE: [0x0000001120000000-0x00000020a0000000] In overlapped range, pages to be ZONE_MOVABLE in ZONE_NORMAL are treated as absent pages, and vice versa. v1 -> v2: Refine so that the above example case also can be handled properly: v2 -> v3: Change the option name from kernelcore=reliable into kernelcore=mirror and some documentation fix according to Andrew Morton's point Taku Izumi (2): mm: Calculate zone_start_pfn at zone_spanned_pages_in_node() mm: Introduce kernelcore=mirror option Documentation/kernel-parameters.txt | 11 ++- mm/page_alloc.c | 140 +++++++++++++++++++++++++++++++----- 2 files changed, 133 insertions(+), 18 deletions(-) -- 1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: Taku Izumi <izumi.taku@jp.fujitsu.com> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: tony.luck@intel.com, qiuxishi@huawei.com, kamezawa.hiroyu@jp.fujitsu.com, mel@csn.ul.ie, dave.hansen@intel.com, matt@codeblueprint.co.uk, Taku Izumi <izumi.taku@jp.fujitsu.com> Subject: [PATCH v3 0/2] mm: Introduce kernelcore=mirror option Date: Wed, 9 Dec 2015 12:18:29 +0900 [thread overview] Message-ID: <1449631109-14756-1-git-send-email-izumi.taku@jp.fujitsu.com> (raw) Xeon E7 v3 based systems supports Address Range Mirroring and UEFI BIOS complied with UEFI spec 2.5 can notify which ranges are mirrored (reliable) via EFI memory map. Now Linux kernel utilize its information and allocates boot time memory from reliable region. My requirement is: - allocate kernel memory from mirrored region - allocate user memory from non-mirrored region In order to meet my requirement, ZONE_MOVABLE is useful. By arranging non-mirrored range into ZONE_MOVABLE, mirrored memory is used for kernel allocations. My idea is to extend existing "kernelcore" option and introduces kernelcore=mirror option. By specifying "mirror" instead of specifying the amount of memory, non-mirrored region will be arranged into ZONE_MOVABLE. Earlier discussions are at: https://lkml.org/lkml/2015/10/9/24 https://lkml.org/lkml/2015/10/15/9 https://lkml.org/lkml/2015/11/27/18 For example, suppose 2-nodes system with the following memory range: node 0 [mem 0x0000000000001000-0x000000109fffffff] node 1 [mem 0x00000010a0000000-0x000000209fffffff] and the following ranges are marked as reliable (mirrored): [0x0000000000000000-0x0000000100000000] [0x0000000100000000-0x0000000180000000] [0x0000000800000000-0x0000000880000000] [0x00000010a0000000-0x0000001120000000] [0x00000017a0000000-0x0000001820000000] If you specify kernelcore=mirror, ZONE_NORMAL and ZONE_MOVABLE are arranged like bellow: - node 0: ZONE_NORMAL : [0x0000000100000000-0x00000010a0000000] ZONE_MOVABLE: [0x0000000180000000-0x00000010a0000000] - node 1: ZONE_NORMAL : [0x00000010a0000000-0x00000020a0000000] ZONE_MOVABLE: [0x0000001120000000-0x00000020a0000000] In overlapped range, pages to be ZONE_MOVABLE in ZONE_NORMAL are treated as absent pages, and vice versa. v1 -> v2: Refine so that the above example case also can be handled properly: v2 -> v3: Change the option name from kernelcore=reliable into kernelcore=mirror and some documentation fix according to Andrew Morton's point Taku Izumi (2): mm: Calculate zone_start_pfn at zone_spanned_pages_in_node() mm: Introduce kernelcore=mirror option Documentation/kernel-parameters.txt | 11 ++- mm/page_alloc.c | 140 +++++++++++++++++++++++++++++++----- 2 files changed, 133 insertions(+), 18 deletions(-) -- 1.9.1 -- 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>
next reply other threads:[~2015-12-09 3:15 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-09 3:18 Taku Izumi [this message] 2015-12-09 3:18 ` [PATCH v3 0/2] mm: Introduce kernelcore=mirror option Taku Izumi 2015-12-09 3:19 ` [PATCH v3 1/2] mm: Calculate zone_start_pfn at zone_spanned_pages_in_node() Taku Izumi 2015-12-09 3:19 ` Taku Izumi 2015-12-09 3:19 ` [PATCH v3 2/2] mm: Introduce kernelcore=mirror option Taku Izumi 2015-12-09 3:19 ` Taku Izumi 2015-12-09 3:28 ` Xishi Qiu 2015-12-09 3:28 ` Xishi Qiu 2015-12-09 21:59 ` Luck, Tony 2015-12-09 21:59 ` Luck, Tony 2015-12-10 1:14 ` Xishi Qiu 2015-12-10 1:14 ` Xishi Qiu 2015-12-10 5:37 ` Izumi, Taku 2015-12-10 5:37 ` Izumi, Taku 2015-12-10 6:13 ` Xishi Qiu 2015-12-10 6:13 ` Xishi Qiu 2015-12-11 5:53 ` Izumi, Taku 2015-12-11 5:53 ` Izumi, Taku 2015-12-11 9:44 ` Xishi Qiu 2015-12-11 9:44 ` Xishi Qiu 2015-12-17 1:38 ` Izumi, Taku 2015-12-17 1:38 ` Izumi, Taku 2015-12-17 2:47 ` Xishi Qiu 2015-12-17 2:47 ` Xishi Qiu 2015-12-17 2:53 ` Kamezawa Hiroyuki 2015-12-17 2:53 ` Kamezawa Hiroyuki 2015-12-17 4:48 ` Xishi Qiu 2015-12-17 4:48 ` Xishi Qiu 2015-12-17 5:01 ` Kamezawa Hiroyuki 2015-12-17 5:01 ` Kamezawa Hiroyuki 2015-12-17 18:43 ` Luck, Tony 2015-12-17 18:43 ` Luck, Tony 2015-12-18 2:12 ` Kamezawa Hiroyuki 2015-12-18 2:12 ` Kamezawa Hiroyuki 2015-12-18 6:59 ` Luck, Tony 2015-12-18 6:59 ` Luck, Tony 2015-12-28 22:21 ` Andrew Morton 2015-12-28 22:21 ` Andrew Morton 2015-12-28 22:32 ` Andrew Morton 2015-12-28 22:32 ` Andrew Morton
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=1449631109-14756-1-git-send-email-izumi.taku@jp.fujitsu.com \ --to=izumi.taku@jp.fujitsu.com \ --cc=akpm@linux-foundation.org \ --cc=dave.hansen@intel.com \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=matt@codeblueprint.co.uk \ --cc=mel@csn.ul.ie \ --cc=qiuxishi@huawei.com \ --cc=tony.luck@intel.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.