From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by kanga.kvack.org (Postfix) with ESMTP id 5F37B6B0266 for ; Mon, 7 May 2018 15:17:07 -0400 (EDT) Received: by mail-oi0-f71.google.com with SMTP id j75-v6so17054072oib.5 for ; Mon, 07 May 2018 12:17:07 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id o103-v6sor5520535ota.25.2018.05.07.12.17.06 for (Google Transport Security); Mon, 07 May 2018 12:17:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1525704627-30114-1-git-send-email-yehs1@lenovo.com> <20180507184622.GB12361@bombadil.infradead.org> From: Dan Williams Date: Mon, 7 May 2018 12:17:05 -0700 Message-ID: Subject: Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Jeff Moyer 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 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 wr= ote: >>> 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=E2=80=99t manage NVDIMM directly as DRAM, ke= rnel uses >>>> corresponding drivers, which locate at \drivers\nvdimm\ and >>>> \drivers\acpi\nfit and fs, to realize NVDIMM memory alloc and free wit= h >>>> 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=E2=80=99s classical features like the bud= dy >>>> system, swap mechanism and page cache couldn=E2=80=99t be supported to= NVDIMM. >>>> What we are doing is to expand kernel mm=E2=80=99s 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.