All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Huaisheng Ye <yehs1@lenovo.com>
Cc: linux-kernel@vger.kernel.org, hehy1@lenovo.com,
	penguin-kernel@I-love.SAKURA.ne.jp, chengnt@lenovo.com,
	linux-nvdimm@lists.01.org, pasha.tatashin@oracle.com,
	willy@infradead.org, alexander.levin@verizon.com,
	linux-mm@kvack.org, hannes@cmpxchg.org,
	akpm@linux-foundation.org, colyli@suse.de,
	mgorman@techsingularity.net, vbabka@suse.cz
Subject: Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
Date: Thu, 10 May 2018 10:41:19 +0200	[thread overview]
Message-ID: <20180510084119.GJ32366@dhcp22.suse.cz> (raw)
In-Reply-To: <20180510075759.GF32366@dhcp22.suse.cz>

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 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.
> > 
> > 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.
> 
> 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
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Huaisheng Ye <yehs1@lenovo.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	willy@infradead.org, vbabka@suse.cz, mgorman@techsingularity.net,
	pasha.tatashin@oracle.com, alexander.levin@verizon.com,
	hannes@cmpxchg.org, penguin-kernel@I-love.SAKURA.ne.jp,
	colyli@suse.de, chengnt@lenovo.com, hehy1@lenovo.com,
	linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org
Subject: Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
Date: Thu, 10 May 2018 10:41:19 +0200	[thread overview]
Message-ID: <20180510084119.GJ32366@dhcp22.suse.cz> (raw)
In-Reply-To: <20180510075759.GF32366@dhcp22.suse.cz>

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 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.
> > 
> > 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.
> 
> 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

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Huaisheng Ye <yehs1@lenovo.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	willy@infradead.org, vbabka@suse.cz, mgorman@techsingularity.net,
	pasha.tatashin@oracle.com, alexander.levin@verizon.com,
	hannes@cmpxchg.org, penguin-kernel@I-love.SAKURA.ne.jp,
	colyli@suse.de, chengnt@lenovo.com, hehy1@lenovo.com,
	linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org
Subject: Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone
Date: Thu, 10 May 2018 10:41:19 +0200	[thread overview]
Message-ID: <20180510084119.GJ32366@dhcp22.suse.cz> (raw)
In-Reply-To: <20180510075759.GF32366@dhcp22.suse.cz>

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

  reply	other threads:[~2018-05-10  8:41 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-08  2:30 [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone Huaisheng Ye
2018-05-08  2:30 ` Huaisheng Ye
     [not found] ` <1525746628-114136-2-git-send-email-yehs1@lenovo.com>
2018-05-08  2:30   ` [External] [RFC PATCH v1 1/6] mm/memblock: Expand definition of flags to support NVDIMM Huaisheng HS1 Ye
2018-05-08  2:30     ` Huaisheng HS1 Ye
2018-05-08  2:30 ` [RFC PATCH v1 4/6] arch/x86/kernel: mark NVDIMM regions from e820_table Huaisheng Ye
     [not found] ` <1525746628-114136-3-git-send-email-yehs1@lenovo.com>
2018-05-08  2:32   ` [External] [RFC PATCH v1 2/6] mm/page_alloc.c: get pfn range with flags of memblock Huaisheng HS1 Ye
2018-05-08  2:32     ` Huaisheng HS1 Ye
     [not found] ` <1525746628-114136-4-git-send-email-yehs1@lenovo.com>
2018-05-08  2:33   ` [External] [RFC PATCH v1 3/6] mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE Huaisheng HS1 Ye
2018-05-08  2:33     ` Huaisheng HS1 Ye
2018-05-08  4:43     ` Randy Dunlap
2018-05-08  4:43       ` Randy Dunlap
2018-05-09  4:22       ` Huaisheng HS1 Ye
2018-05-09  4:22         ` Huaisheng HS1 Ye
2018-05-09 11:47         ` Michal Hocko
2018-05-09 11:47           ` Michal Hocko
2018-05-09 14:04           ` Huaisheng HS1 Ye
2018-05-09 14:04             ` Huaisheng HS1 Ye
2018-05-09 20:56             ` Michal Hocko
2018-05-09 20:56               ` Michal Hocko
2018-05-10  3:53               ` Huaisheng HS1 Ye
2018-05-10  3:53                 ` Huaisheng HS1 Ye
     [not found] ` <1525746628-114136-6-git-send-email-yehs1@lenovo.com>
2018-05-08  2:34   ` [External] [RFC PATCH v1 5/6] mm: get zone spanned pages separately for DRAM and NVDIMM Huaisheng HS1 Ye
2018-05-08  2:34     ` Huaisheng HS1 Ye
     [not found] ` <1525746628-114136-7-git-send-email-yehs1@lenovo.com>
2018-05-08  2:35   ` [External] [RFC PATCH v1 6/6] arch/x86/mm: create page table mapping for DRAM and NVDIMM both Huaisheng HS1 Ye
2018-05-08  2:35     ` Huaisheng HS1 Ye
2018-05-10  7:57 ` [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone Michal Hocko
2018-05-10  7:57   ` Michal Hocko
2018-05-10  7:57   ` Michal Hocko
2018-05-10  8:41   ` Michal Hocko [this message]
2018-05-10  8:41     ` Michal Hocko
2018-05-10  8:41     ` Michal Hocko
  -- strict thread matches above, loose matches on Subject: below --
2018-05-08  2:00 Huaisheng Ye
2018-05-08  2:00 ` Huaisheng Ye
2018-05-07 14:50 Huaisheng Ye
2018-05-07 18:46 ` Matthew Wilcox
2018-05-07 18:46   ` Matthew Wilcox
2018-05-07 18:57   ` Dan Williams
2018-05-07 18:57     ` Dan Williams
2018-05-07 19:08     ` Jeff Moyer
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:28           ` Jeff Moyer
2018-05-07 19:29           ` Dan Williams
2018-05-07 19:29             ` Dan Williams
2018-05-07 19:18     ` Matthew Wilcox
2018-05-07 19:18       ` Matthew Wilcox
2018-05-07 19:30       ` Dan Williams
2018-05-07 19:30         ` Dan Williams

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=20180510084119.GJ32366@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.levin@verizon.com \
    --cc=chengnt@lenovo.com \
    --cc=colyli@suse.de \
    --cc=hannes@cmpxchg.org \
    --cc=hehy1@lenovo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mgorman@techsingularity.net \
    --cc=pasha.tatashin@oracle.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yehs1@lenovo.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: link
Be 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.