* [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
@ 2018-05-08 2:00 Huaisheng Ye
2018-05-08 2:00 ` [RFC PATCH v1 4/6] arch/x86/kernel: mark NVDIMM regions from e820_table Huaisheng Ye
0 siblings, 1 reply; 14+ messages in thread
From: Huaisheng Ye @ 2018-05-08 2:00 UTC (permalink / raw)
To: akpm, linux-mm
Cc: mhocko, willy, vbabka, mgorman, pasha.tatashin, alexander.levin,
hannes, penguin-kernel, colyli, chengnt, hehy1, linux-kernel,
linux-nvdimm, Huaisheng Ye
Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
DEVICE zone, which is a virtual zone and both its start and end of pfn
are equal to 0, mm wouldna??t manage NVDIMM directly as DRAM, kernel uses
corresponding drivers, which locate at \drivers\nvdimm\ and
\drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
memory hot plug implementation.
With current kernel, many mma??s classical features like the buddy
system, swap mechanism and page cache couldna??t be supported to NVDIMM.
What we are doing is to expand kernel mma??s capacity to make it to handle
NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
separately, that means mm can only put the critical pages to NVDIMM
zone, here we created a new zone type as NVM zone. That is to say for
traditional(or normal) pages which would be stored at DRAM scope like
Normal, DMA32 and DMA zones. But for the critical pages, which we hope
them could be recovered from power fail or system crash, we make them
to be persistent by storing them to NVM zone.
We installed two NVDIMMs to Lenovo Thinksystem product as development
platform, which has 125GB storage capacity respectively. With these
patches below, mm can create NVM zones for NVDIMMs.
Here is dmesg info,
Initmem setup node 0 [mem 0x0000000000001000-0x000000237fffffff]
On node 0 totalpages: 36879666
DMA zone: 64 pages used for memmap
DMA zone: 23 pages reserved
DMA zone: 3999 pages, LIFO batch:0
mminit::memmap_init Initialising map node 0 zone 0 pfns 1 -> 4096
DMA32 zone: 10935 pages used for memmap
DMA32 zone: 699795 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 1048576
Normal zone: 53248 pages used for memmap
Normal zone: 3407872 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 2 pfns 1048576 -> 4456448
NVM zone: 512000 pages used for memmap
NVM zone: 32768000 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 3 pfns 4456448 -> 37224448
Initmem setup node 1 [mem 0x0000002380000000-0x00000046bfffffff]
On node 1 totalpages: 36962304
Normal zone: 65536 pages used for memmap
Normal zone: 4194304 pages, LIFO batch:31
mminit::memmap_init Initialising map node 1 zone 2 pfns 37224448 -> 41418752
NVM zone: 512000 pages used for memmap
NVM zone: 32768000 pages, LIFO batch:31
mminit::memmap_init Initialising map node 1 zone 3 pfns 41418752 -> 74186752
This comes /proc/zoneinfo
Node 0, zone NVM
pages free 32768000
min 15244
low 48012
high 80780
spanned 32768000
present 32768000
managed 32768000
protection: (0, 0, 0, 0, 0, 0)
nr_free_pages 32768000
Node 1, zone NVM
pages free 32768000
min 15244
low 48012
high 80780
spanned 32768000
present 32768000
managed 32768000
Huaisheng Ye (6):
mm/memblock: Expand definition of flags to support NVDIMM
mm/page_alloc.c: get pfn range with flags of memblock
mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE
arch/x86/kernel: mark NVDIMM regions from e820_table
mm: get zone spanned pages separately for DRAM and NVDIMM
arch/x86/mm: create page table mapping for DRAM and NVDIMM both
arch/x86/include/asm/e820/api.h | 3 +++
arch/x86/kernel/e820.c | 20 +++++++++++++-
arch/x86/kernel/setup.c | 8 ++++++
arch/x86/mm/init_64.c | 16 +++++++++++
include/linux/gfp.h | 57 ++++++++++++++++++++++++++++++++++++---
include/linux/memblock.h | 19 +++++++++++++
include/linux/mm.h | 4 +++
include/linux/mmzone.h | 3 +++
mm/Kconfig | 16 +++++++++++
mm/memblock.c | 46 +++++++++++++++++++++++++++----
mm/nobootmem.c | 5 ++--
mm/page_alloc.c | 60 ++++++++++++++++++++++++++++++++++++++++-
12 files changed, 245 insertions(+), 12 deletions(-)
--
1.8.3.1
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH v1 4/6] arch/x86/kernel: mark NVDIMM regions from e820_table
2018-05-08 2:00 [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone Huaisheng Ye
@ 2018-05-08 2:00 ` Huaisheng Ye
0 siblings, 0 replies; 14+ messages in thread
From: Huaisheng Ye @ 2018-05-08 2:00 UTC (permalink / raw)
To: akpm, linux-mm
Cc: mhocko, willy, vbabka, mgorman, pasha.tatashin, alexander.levin,
hannes, penguin-kernel, colyli, chengnt, hehy1, linux-kernel,
linux-nvdimm, Huaisheng Ye
During e820__memblock_setup memblock gets entries with type
E820_TYPE_RAM, E820_TYPE_RESERVED_KERN and E820_TYPE_PMEM from
e820_table, then marks NVDIMM regions with flag MEMBLOCK_NVDIMM.
Create function as e820__end_of_nvm_pfn to calculate max_pfn with
NVDIMM region, while zone_sizes_init needs max_pfn to get
arch_zone_lowest/highest_possible_pfn. During free_area_init_nodes,
the possible pfns need to be recalculated for ZONE_NVM.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
Signed-off-by: Ocean He <hehy1@lenovo.com>
---
arch/x86/include/asm/e820/api.h | 3 +++
arch/x86/kernel/e820.c | 20 +++++++++++++++++++-
arch/x86/kernel/setup.c | 8 ++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h
index 62be73b..b8006c3 100644
--- a/arch/x86/include/asm/e820/api.h
+++ b/arch/x86/include/asm/e820/api.h
@@ -22,6 +22,9 @@
extern void e820__update_table_print(void);
extern unsigned long e820__end_of_ram_pfn(void);
+#ifdef CONFIG_ZONE_NVM
+extern unsigned long e820__end_of_nvm_pfn(void);
+#endif
extern unsigned long e820__end_of_low_ram_pfn(void);
extern u64 e820__memblock_alloc_reserved(u64 size, u64 align);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 6a2cb14..1bf7876 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -840,6 +840,13 @@ unsigned long __init e820__end_of_ram_pfn(void)
return e820_end_pfn(MAX_ARCH_PFN, E820_TYPE_RAM);
}
+#ifdef CONFIG_ZONE_NVM
+unsigned long __init e820__end_of_nvm_pfn(void)
+{
+ return e820_end_pfn(MAX_ARCH_PFN, E820_TYPE_PMEM);
+}
+#endif
+
unsigned long __init e820__end_of_low_ram_pfn(void)
{
return e820_end_pfn(1UL << (32 - PAGE_SHIFT), E820_TYPE_RAM);
@@ -1264,11 +1271,22 @@ void __init e820__memblock_setup(void)
end = entry->addr + entry->size;
if (end != (resource_size_t)end)
continue;
-
+#ifdef CONFIG_ZONE_NVM
+ if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN &&
+ entry->type != E820_TYPE_PMEM)
+#else
if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN)
+#endif
continue;
memblock_add(entry->addr, entry->size);
+
+#ifdef CONFIG_ZONE_NVM
+ if (entry->type == E820_TYPE_PMEM) {
+ /* Mark this region with PMEM flags */
+ memblock_mark_nvdimm(entry->addr, entry->size);
+ }
+#endif
}
/* Throw away partial pages: */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 6285697..305975b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1031,7 +1031,15 @@ void __init setup_arch(char **cmdline_p)
* partially used pages are not usable - thus
* we are rounding upwards:
*/
+#ifdef CONFIG_ZONE_NVM
+ max_pfn = e820__end_of_nvm_pfn();
+ if (!max_pfn) {
+ printk(KERN_INFO "No physical NVDIMM has been found\n");
+ max_pfn = e820__end_of_ram_pfn();
+ }
+#else
max_pfn = e820__end_of_ram_pfn();
+#endif
/* update e820 for memory not covered by WB MTRRs */
mtrr_bp_init();
--
1.8.3.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
@ 2018-05-08 2:30 Huaisheng Ye
2018-05-10 7:57 ` Michal Hocko
0 siblings, 1 reply; 14+ messages in thread
From: Huaisheng Ye @ 2018-05-08 2:30 UTC (permalink / raw)
To: akpm, linux-mm
Cc: mhocko, willy, vbabka, mgorman, pasha.tatashin, alexander.levin,
hannes, penguin-kernel, colyli, chengnt, hehy1, linux-kernel,
linux-nvdimm, Huaisheng Ye
Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
DEVICE zone, which is a virtual zone and both its start and end of pfn
are equal to 0, mm wouldna??t manage NVDIMM directly as DRAM, kernel uses
corresponding drivers, which locate at \drivers\nvdimm\ and
\drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
memory hot plug implementation.
With current kernel, many mma??s classical features like the buddy
system, swap mechanism and page cache couldna??t be supported to NVDIMM.
What we are doing is to expand kernel mma??s capacity to make it to handle
NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
separately, that means mm can only put the critical pages to NVDIMM
zone, here we created a new zone type as NVM zone. That is to say for
traditional(or normal) pages which would be stored at DRAM scope like
Normal, DMA32 and DMA zones. But for the critical pages, which we hope
them could be recovered from power fail or system crash, we make them
to be persistent by storing them to NVM zone.
We installed two NVDIMMs to Lenovo Thinksystem product as development
platform, which has 125GB storage capacity respectively. With these
patches below, mm can create NVM zones for NVDIMMs.
Here is dmesg info,
Initmem setup node 0 [mem 0x0000000000001000-0x000000237fffffff]
On node 0 totalpages: 36879666
DMA zone: 64 pages used for memmap
DMA zone: 23 pages reserved
DMA zone: 3999 pages, LIFO batch:0
mminit::memmap_init Initialising map node 0 zone 0 pfns 1 -> 4096
DMA32 zone: 10935 pages used for memmap
DMA32 zone: 699795 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 1048576
Normal zone: 53248 pages used for memmap
Normal zone: 3407872 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 2 pfns 1048576 -> 4456448
NVM zone: 512000 pages used for memmap
NVM zone: 32768000 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 3 pfns 4456448 -> 37224448
Initmem setup node 1 [mem 0x0000002380000000-0x00000046bfffffff]
On node 1 totalpages: 36962304
Normal zone: 65536 pages used for memmap
Normal zone: 4194304 pages, LIFO batch:31
mminit::memmap_init Initialising map node 1 zone 2 pfns 37224448 -> 41418752
NVM zone: 512000 pages used for memmap
NVM zone: 32768000 pages, LIFO batch:31
mminit::memmap_init Initialising map node 1 zone 3 pfns 41418752 -> 74186752
This comes /proc/zoneinfo
Node 0, zone NVM
pages free 32768000
min 15244
low 48012
high 80780
spanned 32768000
present 32768000
managed 32768000
protection: (0, 0, 0, 0, 0, 0)
nr_free_pages 32768000
Node 1, zone NVM
pages free 32768000
min 15244
low 48012
high 80780
spanned 32768000
present 32768000
managed 32768000
Huaisheng Ye (6):
mm/memblock: Expand definition of flags to support NVDIMM
mm/page_alloc.c: get pfn range with flags of memblock
mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE
arch/x86/kernel: mark NVDIMM regions from e820_table
mm: get zone spanned pages separately for DRAM and NVDIMM
arch/x86/mm: create page table mapping for DRAM and NVDIMM both
arch/x86/include/asm/e820/api.h | 3 +++
arch/x86/kernel/e820.c | 20 +++++++++++++-
arch/x86/kernel/setup.c | 8 ++++++
arch/x86/mm/init_64.c | 16 +++++++++++
include/linux/gfp.h | 57 ++++++++++++++++++++++++++++++++++++---
include/linux/memblock.h | 19 +++++++++++++
include/linux/mm.h | 4 +++
include/linux/mmzone.h | 3 +++
mm/Kconfig | 16 +++++++++++
mm/memblock.c | 46 +++++++++++++++++++++++++++----
mm/nobootmem.c | 5 ++--
mm/page_alloc.c | 60 ++++++++++++++++++++++++++++++++++++++++-
12 files changed, 245 insertions(+), 12 deletions(-)
--
1.8.3.1
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-08 2:30 [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone Huaisheng Ye
@ 2018-05-10 7:57 ` Michal Hocko
2018-05-10 8:41 ` Michal Hocko
0 siblings, 1 reply; 14+ messages in thread
From: Michal Hocko @ 2018-05-10 7:57 UTC (permalink / raw)
To: Huaisheng Ye
Cc: akpm, linux-mm, willy, vbabka, mgorman, pasha.tatashin,
alexander.levin, hannes, penguin-kernel, colyli, chengnt, hehy1,
linux-kernel, linux-nvdimm
On Tue 08-05-18 10:30:22, Huaisheng Ye wrote:
> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
> DEVICE zone, which is a virtual zone and both its start and end of pfn
> are equal to 0, mm wouldna??t manage NVDIMM directly as DRAM, kernel uses
> corresponding drivers, which locate at \drivers\nvdimm\ and
> \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
> memory hot plug implementation.
>
> With current kernel, many mma??s classical features like the buddy
> system, swap mechanism and page cache couldna??t be supported to NVDIMM.
> What we are doing is to expand kernel mma??s capacity to make it to handle
> NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
> separately, that means mm can only put the critical pages to NVDIMM
> zone, here we created a new zone type as NVM zone.
How do you define critical pages? Who is allowed to allocate from them?
You do not seem to add _any_ user of GFP_NVM.
> That is to say for
> traditional(or normal) pages which would be stored at DRAM scope like
> Normal, DMA32 and DMA zones. But for the critical pages, which we hope
> them could be recovered from power fail or system crash, we make them
> to be persistent by storing them to NVM zone.
This brings more questions than it answers. First of all is this going
to be any guarantee? Let's say I want GFP_NVM, can I get memory from
other zones? In other words is such a request allowed to fallback to
succeed? Are we allowed to reclaim memory from the new zone? What should
happen on the OOM? How is the user expected to restore the previous
content after reboot/crash?
I am sorry if these questions are answered in the respective patches but
it would be great to have this in the cover letter to have a good
overview of the whole design. From my quick glance over patches my
previous concerns about an additional zone still hold, though.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-10 7:57 ` Michal Hocko
@ 2018-05-10 8:41 ` Michal Hocko
0 siblings, 0 replies; 14+ messages in thread
From: Michal Hocko @ 2018-05-10 8:41 UTC (permalink / raw)
To: Huaisheng Ye
Cc: akpm, linux-mm, willy, vbabka, mgorman, pasha.tatashin,
alexander.levin, hannes, penguin-kernel, colyli, chengnt, hehy1,
linux-kernel, linux-nvdimm
I have only now noticed that you have posted this few days ago
http://lkml.kernel.org/r/1525704627-30114-1-git-send-email-yehs1@lenovo.com
There were some good questions asked there and I have many that are
common yet they are not covered in the cover letter. Please _always_
make sure to answer review comments before reposting. Otherwise some
important parts gets lost on the way.
On Thu 10-05-18 09:57:59, Michal Hocko wrote:
> On Tue 08-05-18 10:30:22, Huaisheng Ye wrote:
> > Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
> > DEVICE zone, which is a virtual zone and both its start and end of pfn
> > are equal to 0, mm wouldna??t manage NVDIMM directly as DRAM, kernel uses
> > corresponding drivers, which locate at \drivers\nvdimm\ and
> > \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
> > memory hot plug implementation.
> >
> > With current kernel, many mma??s classical features like the buddy
> > system, swap mechanism and page cache couldna??t be supported to NVDIMM.
> > What we are doing is to expand kernel mma??s capacity to make it to handle
> > NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
> > separately, that means mm can only put the critical pages to NVDIMM
> > zone, here we created a new zone type as NVM zone.
>
> How do you define critical pages? Who is allowed to allocate from them?
> You do not seem to add _any_ user of GFP_NVM.
>
> > That is to say for
> > traditional(or normal) pages which would be stored at DRAM scope like
> > Normal, DMA32 and DMA zones. But for the critical pages, which we hope
> > them could be recovered from power fail or system crash, we make them
> > to be persistent by storing them to NVM zone.
>
> This brings more questions than it answers. First of all is this going
> to be any guarantee? Let's say I want GFP_NVM, can I get memory from
> other zones? In other words is such a request allowed to fallback to
> succeed? Are we allowed to reclaim memory from the new zone? What should
> happen on the OOM? How is the user expected to restore the previous
> content after reboot/crash?
>
> I am sorry if these questions are answered in the respective patches but
> it would be great to have this in the cover letter to have a good
> overview of the whole design. From my quick glance over patches my
> previous concerns about an additional zone still hold, though.
> --
> Michal Hocko
> SUSE Labs
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
@ 2018-05-07 14:50 Huaisheng Ye
2018-05-07 18:46 ` Matthew Wilcox
0 siblings, 1 reply; 14+ messages in thread
From: Huaisheng Ye @ 2018-05-07 14:50 UTC (permalink / raw)
To: akpm, linux-mm
Cc: mhocko, willy, vbabka, mgorman, pasha.tatashin, alexander.levin,
hannes, penguin-kernel, colyli, chengnt, linux-kernel,
Huaisheng Ye
Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
DEVICE zone, which is a virtual zone and both its start and end of pfn
are equal to 0, mm wouldna??t manage NVDIMM directly as DRAM, kernel uses
corresponding drivers, which locate at \drivers\nvdimm\ and
\drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
memory hot plug implementation.
With current kernel, many mma??s classical features like the buddy
system, swap mechanism and page cache couldna??t be supported to NVDIMM.
What we are doing is to expand kernel mma??s capacity to make it to handle
NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
separately, that means mm can only put the critical pages to NVDIMM
zone, here we created a new zone type as NVM zone. That is to say for
traditional(or normal) pages which would be stored at DRAM scope like
Normal, DMA32 and DMA zones. But for the critical pages, which we hope
them could be recovered from power fail or system crash, we make them
to be persistent by storing them to NVM zone.
We installed two NVDIMMs to Lenovo Thinksystem product as development
platform, which has 125GB storage capacity respectively. With these
patches below, mm can create NVM zones for NVDIMMs.
Here is dmesg info,
Initmem setup node 0 [mem 0x0000000000001000-0x000000237fffffff]
On node 0 totalpages: 36879666
DMA zone: 64 pages used for memmap
DMA zone: 23 pages reserved
DMA zone: 3999 pages, LIFO batch:0
mminit::memmap_init Initialising map node 0 zone 0 pfns 1 -> 4096
DMA32 zone: 10935 pages used for memmap
DMA32 zone: 699795 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 1048576
Normal zone: 53248 pages used for memmap
Normal zone: 3407872 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 2 pfns 1048576 -> 4456448
NVM zone: 512000 pages used for memmap
NVM zone: 32768000 pages, LIFO batch:31
mminit::memmap_init Initialising map node 0 zone 3 pfns 4456448 -> 37224448
Initmem setup node 1 [mem 0x0000002380000000-0x00000046bfffffff]
On node 1 totalpages: 36962304
Normal zone: 65536 pages used for memmap
Normal zone: 4194304 pages, LIFO batch:31
mminit::memmap_init Initialising map node 1 zone 2 pfns 37224448 -> 41418752
NVM zone: 512000 pages used for memmap
NVM zone: 32768000 pages, LIFO batch:31
mminit::memmap_init Initialising map node 1 zone 3 pfns 41418752 -> 74186752
This comes /proc/zoneinfo
Node 0, zone NVM
pages free 32768000
min 15244
low 48012
high 80780
spanned 32768000
present 32768000
managed 32768000
protection: (0, 0, 0, 0, 0, 0)
nr_free_pages 32768000
Node 1, zone NVM
pages free 32768000
min 15244
low 48012
high 80780
spanned 32768000
present 32768000
managed 32768000
Huaisheng Ye (6):
mm/memblock: Expand definition of flags to support NVDIMM
mm/page_alloc.c: get pfn range with flags of memblock
mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE
arch/x86/kernel: mark NVDIMM regions from e820_table
mm: get zone spanned pages separately for DRAM and NVDIMM
arch/x86/mm: create page table mapping for DRAM and NVDIMM both
arch/x86/include/asm/e820/api.h | 3 +++
arch/x86/kernel/e820.c | 20 +++++++++++++-
arch/x86/kernel/setup.c | 8 ++++++
arch/x86/mm/init_64.c | 16 +++++++++++
include/linux/gfp.h | 57 ++++++++++++++++++++++++++++++++++++---
include/linux/memblock.h | 19 +++++++++++++
include/linux/mm.h | 4 +++
include/linux/mmzone.h | 3 +++
mm/Kconfig | 16 +++++++++++
mm/memblock.c | 46 +++++++++++++++++++++++++++----
mm/nobootmem.c | 5 ++--
mm/page_alloc.c | 60 ++++++++++++++++++++++++++++++++++++++++-
12 files changed, 245 insertions(+), 12 deletions(-)
--
1.8.3.1
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-07 14:50 Huaisheng Ye
@ 2018-05-07 18:46 ` Matthew Wilcox
2018-05-07 18:57 ` Dan Williams
0 siblings, 1 reply; 14+ messages in thread
From: Matthew Wilcox @ 2018-05-07 18:46 UTC (permalink / raw)
To: Huaisheng Ye
Cc: akpm, linux-mm, mhocko, vbabka, mgorman, pasha.tatashin,
alexander.levin, hannes, penguin-kernel, colyli, chengnt,
linux-kernel, linux-nvdimm
On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
> DEVICE zone, which is a virtual zone and both its start and end of pfn
> are equal to 0, mm wouldna??t manage NVDIMM directly as DRAM, kernel uses
> corresponding drivers, which locate at \drivers\nvdimm\ and
> \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
> memory hot plug implementation.
You probably want to let linux-nvdimm know about this patch set.
Adding to the cc. Also, I only received patch 0 and 4. What happened
to 1-3,5 and 6?
> With current kernel, many mma??s classical features like the buddy
> system, swap mechanism and page cache couldna??t be supported to NVDIMM.
> What we are doing is to expand kernel mma??s capacity to make it to handle
> NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
> separately, that means mm can only put the critical pages to NVDIMM
> zone, here we created a new zone type as NVM zone. That is to say for
> traditional(or normal) pages which would be stored at DRAM scope like
> Normal, DMA32 and DMA zones. But for the critical pages, which we hope
> them could be recovered from power fail or system crash, we make them
> to be persistent by storing them to NVM zone.
>
> We installed two NVDIMMs to Lenovo Thinksystem product as development
> platform, which has 125GB storage capacity respectively. With these
> patches below, mm can create NVM zones for NVDIMMs.
>
> Here is dmesg info,
> Initmem setup node 0 [mem 0x0000000000001000-0x000000237fffffff]
> On node 0 totalpages: 36879666
> DMA zone: 64 pages used for memmap
> DMA zone: 23 pages reserved
> DMA zone: 3999 pages, LIFO batch:0
> mminit::memmap_init Initialising map node 0 zone 0 pfns 1 -> 4096
> DMA32 zone: 10935 pages used for memmap
> DMA32 zone: 699795 pages, LIFO batch:31
> mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 1048576
> Normal zone: 53248 pages used for memmap
> Normal zone: 3407872 pages, LIFO batch:31
> mminit::memmap_init Initialising map node 0 zone 2 pfns 1048576 -> 4456448
> NVM zone: 512000 pages used for memmap
> NVM zone: 32768000 pages, LIFO batch:31
> mminit::memmap_init Initialising map node 0 zone 3 pfns 4456448 -> 37224448
> Initmem setup node 1 [mem 0x0000002380000000-0x00000046bfffffff]
> On node 1 totalpages: 36962304
> Normal zone: 65536 pages used for memmap
> Normal zone: 4194304 pages, LIFO batch:31
> mminit::memmap_init Initialising map node 1 zone 2 pfns 37224448 -> 41418752
> NVM zone: 512000 pages used for memmap
> NVM zone: 32768000 pages, LIFO batch:31
> mminit::memmap_init Initialising map node 1 zone 3 pfns 41418752 -> 74186752
>
> This comes /proc/zoneinfo
> Node 0, zone NVM
> pages free 32768000
> min 15244
> low 48012
> high 80780
> spanned 32768000
> present 32768000
> managed 32768000
> protection: (0, 0, 0, 0, 0, 0)
> nr_free_pages 32768000
> Node 1, zone NVM
> pages free 32768000
> min 15244
> low 48012
> high 80780
> spanned 32768000
> present 32768000
> managed 32768000
>
> Huaisheng Ye (6):
> mm/memblock: Expand definition of flags to support NVDIMM
> mm/page_alloc.c: get pfn range with flags of memblock
> mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE
> arch/x86/kernel: mark NVDIMM regions from e820_table
> mm: get zone spanned pages separately for DRAM and NVDIMM
> arch/x86/mm: create page table mapping for DRAM and NVDIMM both
>
> arch/x86/include/asm/e820/api.h | 3 +++
> arch/x86/kernel/e820.c | 20 +++++++++++++-
> arch/x86/kernel/setup.c | 8 ++++++
> arch/x86/mm/init_64.c | 16 +++++++++++
> include/linux/gfp.h | 57 ++++++++++++++++++++++++++++++++++++---
> include/linux/memblock.h | 19 +++++++++++++
> include/linux/mm.h | 4 +++
> include/linux/mmzone.h | 3 +++
> mm/Kconfig | 16 +++++++++++
> mm/memblock.c | 46 +++++++++++++++++++++++++++----
> mm/nobootmem.c | 5 ++--
> mm/page_alloc.c | 60 ++++++++++++++++++++++++++++++++++++++++-
> 12 files changed, 245 insertions(+), 12 deletions(-)
>
> --
> 1.8.3.1
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-07 18:46 ` Matthew Wilcox
@ 2018-05-07 18:57 ` Dan Williams
2018-05-07 19:08 ` Jeff Moyer
2018-05-07 19:18 ` Matthew Wilcox
0 siblings, 2 replies; 14+ messages in thread
From: Dan Williams @ 2018-05-07 18:57 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Huaisheng Ye, Michal Hocko, Linux Kernel Mailing List,
linux-nvdimm, Tetsuo Handa, chengnt, pasha.tatashin, Sasha Levin,
Linux MM, Johannes Weiner, Andrew Morton, colyli, Mel Gorman,
Vlastimil Babka, Dave Hansen
On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox <willy@infradead.org> wrote:
> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
>> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
>> DEVICE zone, which is a virtual zone and both its start and end of pfn
>> are equal to 0, mm wouldn’t manage NVDIMM directly as DRAM, kernel uses
>> corresponding drivers, which locate at \drivers\nvdimm\ and
>> \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
>> memory hot plug implementation.
>
> You probably want to let linux-nvdimm know about this patch set.
> Adding to the cc.
Yes, thanks for that!
> Also, I only received patch 0 and 4. What happened
> to 1-3,5 and 6?
>
>> With current kernel, many mm’s classical features like the buddy
>> system, swap mechanism and page cache couldn’t be supported to NVDIMM.
>> What we are doing is to expand kernel mm’s capacity to make it to handle
>> NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
>> separately, that means mm can only put the critical pages to NVDIMM
>> zone, here we created a new zone type as NVM zone. That is to say for
>> traditional(or normal) pages which would be stored at DRAM scope like
>> Normal, DMA32 and DMA zones. But for the critical pages, which we hope
>> them could be recovered from power fail or system crash, we make them
>> to be persistent by storing them to NVM zone.
>>
>> We installed two NVDIMMs to Lenovo Thinksystem product as development
>> platform, which has 125GB storage capacity respectively. With these
>> patches below, mm can create NVM zones for NVDIMMs.
>>
>> Here is dmesg info,
>> Initmem setup node 0 [mem 0x0000000000001000-0x000000237fffffff]
>> On node 0 totalpages: 36879666
>> DMA zone: 64 pages used for memmap
>> DMA zone: 23 pages reserved
>> DMA zone: 3999 pages, LIFO batch:0
>> mminit::memmap_init Initialising map node 0 zone 0 pfns 1 -> 4096
>> DMA32 zone: 10935 pages used for memmap
>> DMA32 zone: 699795 pages, LIFO batch:31
>> mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 1048576
>> Normal zone: 53248 pages used for memmap
>> Normal zone: 3407872 pages, LIFO batch:31
>> mminit::memmap_init Initialising map node 0 zone 2 pfns 1048576 -> 4456448
>> NVM zone: 512000 pages used for memmap
>> NVM zone: 32768000 pages, LIFO batch:31
>> mminit::memmap_init Initialising map node 0 zone 3 pfns 4456448 -> 37224448
>> Initmem setup node 1 [mem 0x0000002380000000-0x00000046bfffffff]
>> On node 1 totalpages: 36962304
>> Normal zone: 65536 pages used for memmap
>> Normal zone: 4194304 pages, LIFO batch:31
>> mminit::memmap_init Initialising map node 1 zone 2 pfns 37224448 -> 41418752
>> NVM zone: 512000 pages used for memmap
>> NVM zone: 32768000 pages, LIFO batch:31
>> mminit::memmap_init Initialising map node 1 zone 3 pfns 41418752 -> 74186752
>>
>> This comes /proc/zoneinfo
>> Node 0, zone NVM
>> pages free 32768000
>> min 15244
>> low 48012
>> high 80780
>> spanned 32768000
>> present 32768000
>> managed 32768000
>> protection: (0, 0, 0, 0, 0, 0)
>> nr_free_pages 32768000
>> Node 1, zone NVM
>> pages free 32768000
>> min 15244
>> low 48012
>> high 80780
>> spanned 32768000
>> present 32768000
>> managed 32768000
I think adding yet one more mm-zone is the wrong direction. Instead,
what we have been considering is a mechanism to allow a device-dax
instance to be given back to the kernel as a distinct numa node
managed by the VM. It seems it times to dust off those patches.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-07 18:57 ` Dan Williams
@ 2018-05-07 19:08 ` Jeff Moyer
2018-05-07 19:17 ` Dan Williams
2018-05-07 19:18 ` Matthew Wilcox
1 sibling, 1 reply; 14+ messages in thread
From: Jeff Moyer @ 2018-05-07 19:08 UTC (permalink / raw)
To: Dan Williams
Cc: Matthew Wilcox, Michal Hocko, Huaisheng Ye, linux-nvdimm,
Tetsuo Handa, chengnt, Dave Hansen, Linux Kernel Mailing List,
pasha.tatashin, Linux MM, colyli, Johannes Weiner, Andrew Morton,
Sasha Levin, Mel Gorman, Vlastimil Babka
Dan Williams <dan.j.williams@intel.com> writes:
> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox <willy@infradead.org> wrote:
>> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
>>> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
>>> DEVICE zone, which is a virtual zone and both its start and end of pfn
>>> are equal to 0, mm wouldn’t manage NVDIMM directly as DRAM, kernel uses
>>> corresponding drivers, which locate at \drivers\nvdimm\ and
>>> \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
>>> memory hot plug implementation.
>>
>> You probably want to let linux-nvdimm know about this patch set.
>> Adding to the cc.
>
> Yes, thanks for that!
>
>> Also, I only received patch 0 and 4. What happened
>> to 1-3,5 and 6?
>>
>>> With current kernel, many mm’s classical features like the buddy
>>> system, swap mechanism and page cache couldn’t be supported to NVDIMM.
>>> What we are doing is to expand kernel mm’s capacity to make it to handle
>>> NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
>>> separately, that means mm can only put the critical pages to NVDIMM
Please define "critical pages."
>>> zone, here we created a new zone type as NVM zone. That is to say for
>>> traditional(or normal) pages which would be stored at DRAM scope like
>>> Normal, DMA32 and DMA zones. But for the critical pages, which we hope
>>> them could be recovered from power fail or system crash, we make them
>>> to be persistent by storing them to NVM zone.
[...]
> I think adding yet one more mm-zone is the wrong direction. Instead,
> what we have been considering is a mechanism to allow a device-dax
> instance to be given back to the kernel as a distinct numa node
> managed by the VM. It seems it times to dust off those patches.
What's the use case? The above patch description seems to indicate an
intent to recover contents after a power loss. Without seeing the whole
series, I'm not sure how that's accomplished in a safe or meaningful
way.
Huaisheng, could you provide a bit more background?
Thanks!
Jeff
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-07 19:08 ` Jeff Moyer
@ 2018-05-07 19:17 ` Dan Williams
2018-05-07 19:28 ` Jeff Moyer
0 siblings, 1 reply; 14+ messages in thread
From: Dan Williams @ 2018-05-07 19:17 UTC (permalink / raw)
To: Jeff Moyer
Cc: Matthew Wilcox, Michal Hocko, Huaisheng Ye, linux-nvdimm,
Tetsuo Handa, chengnt, Dave Hansen, Linux Kernel Mailing List,
pasha.tatashin, Linux MM, colyli, Johannes Weiner, Andrew Morton,
Sasha Levin, Mel Gorman, Vlastimil Babka
On Mon, May 7, 2018 at 12:08 PM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Dan Williams <dan.j.williams@intel.com> writes:
>
>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox <willy@infradead.org> wrote:
>>> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
>>>> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
>>>> DEVICE zone, which is a virtual zone and both its start and end of pfn
>>>> are equal to 0, mm wouldn’t manage NVDIMM directly as DRAM, kernel uses
>>>> corresponding drivers, which locate at \drivers\nvdimm\ and
>>>> \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
>>>> memory hot plug implementation.
>>>
>>> You probably want to let linux-nvdimm know about this patch set.
>>> Adding to the cc.
>>
>> Yes, thanks for that!
>>
>>> Also, I only received patch 0 and 4. What happened
>>> to 1-3,5 and 6?
>>>
>>>> With current kernel, many mm’s classical features like the buddy
>>>> system, swap mechanism and page cache couldn’t be supported to NVDIMM.
>>>> What we are doing is to expand kernel mm’s capacity to make it to handle
>>>> NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
>>>> separately, that means mm can only put the critical pages to NVDIMM
>
> Please define "critical pages."
>
>>>> zone, here we created a new zone type as NVM zone. That is to say for
>>>> traditional(or normal) pages which would be stored at DRAM scope like
>>>> Normal, DMA32 and DMA zones. But for the critical pages, which we hope
>>>> them could be recovered from power fail or system crash, we make them
>>>> to be persistent by storing them to NVM zone.
>
> [...]
>
>> I think adding yet one more mm-zone is the wrong direction. Instead,
>> what we have been considering is a mechanism to allow a device-dax
>> instance to be given back to the kernel as a distinct numa node
>> managed by the VM. It seems it times to dust off those patches.
>
> What's the use case?
Use NVDIMMs as System-RAM given their potentially higher capacity than
DDR. The expectation in that case is that data is forfeit (not
persisted) after a crash. Any persistent use case would need to go
through the pmem driver, filesystem-dax or device-dax.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-07 19:17 ` Dan Williams
@ 2018-05-07 19:28 ` Jeff Moyer
2018-05-07 19:29 ` Dan Williams
0 siblings, 1 reply; 14+ messages in thread
From: Jeff Moyer @ 2018-05-07 19:28 UTC (permalink / raw)
To: Dan Williams
Cc: Matthew Wilcox, Michal Hocko, Huaisheng Ye, linux-nvdimm,
Tetsuo Handa, chengnt, Dave Hansen, Linux Kernel Mailing List,
pasha.tatashin, Linux MM, colyli, Johannes Weiner, Andrew Morton,
Sasha Levin, Mel Gorman, Vlastimil Babka
Dan Williams <dan.j.williams@intel.com> writes:
> On Mon, May 7, 2018 at 12:08 PM, Jeff Moyer <jmoyer@redhat.com> wrote:
>> Dan Williams <dan.j.williams@intel.com> writes:
>>
>>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox <willy@infradead.org> wrote:
>>>> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote:
>>>>> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as
>>>>> DEVICE zone, which is a virtual zone and both its start and end of pfn
>>>>> are equal to 0, mm wouldn’t manage NVDIMM directly as DRAM, kernel uses
>>>>> corresponding drivers, which locate at \drivers\nvdimm\ and
>>>>> \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free with
>>>>> memory hot plug implementation.
>>>>
>>>> You probably want to let linux-nvdimm know about this patch set.
>>>> Adding to the cc.
>>>
>>> Yes, thanks for that!
>>>
>>>> Also, I only received patch 0 and 4. What happened
>>>> to 1-3,5 and 6?
>>>>
>>>>> With current kernel, many mm’s classical features like the buddy
>>>>> system, swap mechanism and page cache couldn’t be supported to NVDIMM.
>>>>> What we are doing is to expand kernel mm’s capacity to make it to handle
>>>>> NVDIMM like DRAM. Furthermore we make mm could treat DRAM and NVDIMM
>>>>> separately, that means mm can only put the critical pages to NVDIMM
>>
>> Please define "critical pages."
>>
>>>>> zone, here we created a new zone type as NVM zone. That is to say for
>>>>> traditional(or normal) pages which would be stored at DRAM scope like
>>>>> Normal, DMA32 and DMA zones. But for the critical pages, which we hope
>>>>> them could be recovered from power fail or system crash, we make them
>>>>> to be persistent by storing them to NVM zone.
>>
>> [...]
>>
>>> I think adding yet one more mm-zone is the wrong direction. Instead,
>>> what we have been considering is a mechanism to allow a device-dax
>>> instance to be given back to the kernel as a distinct numa node
>>> managed by the VM. It seems it times to dust off those patches.
>>
>> What's the use case?
>
> Use NVDIMMs as System-RAM given their potentially higher capacity than
> DDR. The expectation in that case is that data is forfeit (not
> persisted) after a crash. Any persistent use case would need to go
> through the pmem driver, filesystem-dax or device-dax.
OK, but that sounds different from what was being proposed, here. I'll
quote from above:
>>>>> But for the critical pages, which we hope them could be recovered
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> from power fail or system crash, we make them to be persistent by
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> storing them to NVM zone.
Hence my confusion.
Cheers,
Jeff
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-07 19:28 ` Jeff Moyer
@ 2018-05-07 19:29 ` Dan Williams
0 siblings, 0 replies; 14+ messages in thread
From: Dan Williams @ 2018-05-07 19:29 UTC (permalink / raw)
To: Jeff Moyer
Cc: Matthew Wilcox, Michal Hocko, Huaisheng Ye, linux-nvdimm,
Tetsuo Handa, chengnt, Dave Hansen, Linux Kernel Mailing List,
pasha.tatashin, Linux MM, colyli, Johannes Weiner, Andrew Morton,
Sasha Levin, Mel Gorman, Vlastimil Babka
On Mon, May 7, 2018 at 12:28 PM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Dan Williams <dan.j.williams@intel.com> writes:
[..]
>>> What's the use case?
>>
>> Use NVDIMMs as System-RAM given their potentially higher capacity than
>> DDR. The expectation in that case is that data is forfeit (not
>> persisted) after a crash. Any persistent use case would need to go
>> through the pmem driver, filesystem-dax or device-dax.
>
> OK, but that sounds different from what was being proposed, here. I'll
> quote from above:
>
>>>>>> But for the critical pages, which we hope them could be recovered
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> from power fail or system crash, we make them to be persistent by
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> storing them to NVM zone.
>
> Hence my confusion.
Yes, now mine too, I overlooked that.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-07 18:57 ` Dan Williams
2018-05-07 19:08 ` Jeff Moyer
@ 2018-05-07 19:18 ` Matthew Wilcox
2018-05-07 19:30 ` Dan Williams
1 sibling, 1 reply; 14+ messages in thread
From: Matthew Wilcox @ 2018-05-07 19:18 UTC (permalink / raw)
To: Dan Williams
Cc: Huaisheng Ye, Michal Hocko, Linux Kernel Mailing List,
linux-nvdimm, Tetsuo Handa, chengnt, pasha.tatashin, Sasha Levin,
Linux MM, Johannes Weiner, Andrew Morton, colyli, Mel Gorman,
Vlastimil Babka, Dave Hansen
On Mon, May 07, 2018 at 11:57:10AM -0700, Dan Williams wrote:
> I think adding yet one more mm-zone is the wrong direction. Instead,
> what we have been considering is a mechanism to allow a device-dax
> instance to be given back to the kernel as a distinct numa node
> managed by the VM. It seems it times to dust off those patches.
I was wondering how "safe" we think that ability is. NV-DIMM pages
(obviously) differ from normal pages by their non-volatility. Do we
want their contents from the previous boot to be observable? If not,
then we need the BIOS to clear them at boot-up, which means we would
want no kernel changes at all; rather the BIOS should just describe
those pages as if they were DRAM (after zeroing them).
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
2018-05-07 19:18 ` Matthew Wilcox
@ 2018-05-07 19:30 ` Dan Williams
0 siblings, 0 replies; 14+ messages in thread
From: Dan Williams @ 2018-05-07 19:30 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Huaisheng Ye, Michal Hocko, Linux Kernel Mailing List,
linux-nvdimm, Tetsuo Handa, chengnt, pasha.tatashin, Sasha Levin,
Linux MM, Johannes Weiner, Andrew Morton, colyli, Mel Gorman,
Vlastimil Babka, Dave Hansen
On Mon, May 7, 2018 at 12:18 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Mon, May 07, 2018 at 11:57:10AM -0700, Dan Williams wrote:
>> I think adding yet one more mm-zone is the wrong direction. Instead,
>> what we have been considering is a mechanism to allow a device-dax
>> instance to be given back to the kernel as a distinct numa node
>> managed by the VM. It seems it times to dust off those patches.
>
> I was wondering how "safe" we think that ability is. NV-DIMM pages
> (obviously) differ from normal pages by their non-volatility. Do we
> want their contents from the previous boot to be observable? If not,
> then we need the BIOS to clear them at boot-up, which means we would
> want no kernel changes at all; rather the BIOS should just describe
> those pages as if they were DRAM (after zeroing them).
Certainly the BIOS could do it, but the impetus for having a kernel
mechanism to do the same is for supporting the configuration
flexibility afforded by namespaces, or otherwise having the capability
when the BIOS does not offer it. However, you are right that there are
extra security implications when System-RAM is persisted, perhaps
requiring the capacity to be explicitly locked / unlocked could
address that concern?
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-05-10 8:41 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-08 2:00 [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone Huaisheng Ye
2018-05-08 2:00 ` [RFC PATCH v1 4/6] arch/x86/kernel: mark NVDIMM regions from e820_table Huaisheng Ye
-- strict thread matches above, loose matches on Subject: below --
2018-05-08 2:30 [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone Huaisheng Ye
2018-05-10 7:57 ` Michal Hocko
2018-05-10 8:41 ` Michal Hocko
2018-05-07 14:50 Huaisheng Ye
2018-05-07 18:46 ` Matthew Wilcox
2018-05-07 18:57 ` Dan Williams
2018-05-07 19:08 ` Jeff Moyer
2018-05-07 19:17 ` Dan Williams
2018-05-07 19:28 ` Jeff Moyer
2018-05-07 19:29 ` Dan Williams
2018-05-07 19:18 ` Matthew Wilcox
2018-05-07 19:30 ` Dan Williams
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).