From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752811AbeEGT2d convert rfc822-to-8bit (ORCPT ); Mon, 7 May 2018 15:28:33 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44276 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752721AbeEGT2b (ORCPT ); Mon, 7 May 2018 15:28:31 -0400 From: Jeff Moyer To: Dan Williams Cc: Matthew Wilcox , Michal Hocko , Huaisheng Ye , linux-nvdimm , Tetsuo Handa , chengnt@lenovo.com, Dave Hansen , Linux Kernel Mailing List , pasha.tatashin@oracle.com, Linux MM , colyli@suse.de, Johannes Weiner , Andrew Morton , Sasha Levin , Mel Gorman , Vlastimil Babka Subject: Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone References: <1525704627-30114-1-git-send-email-yehs1@lenovo.com> <20180507184622.GB12361@bombadil.infradead.org> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Mon, 07 May 2018 15:28:29 -0400 In-Reply-To: (Dan Williams's message of "Mon, 7 May 2018 12:17:05 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dan Williams writes: > On Mon, May 7, 2018 at 12:08 PM, Jeff Moyer wrote: >> Dan Williams writes: >> >>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox 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