From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f200.google.com (mail-qk0-f200.google.com [209.85.220.200]) by kanga.kvack.org (Postfix) with ESMTP id E7B5E6B000D for ; Mon, 7 May 2018 15:08:36 -0400 (EDT) Received: by mail-qk0-f200.google.com with SMTP id 187so7010412qkh.16 for ; Mon, 07 May 2018 12:08:36 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id o16-v6si3518487qvc.68.2018.05.07.12.08.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 12:08:36 -0700 (PDT) From: Jeff Moyer 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> Date: Mon, 07 May 2018 15:08:32 -0400 In-Reply-To: (Dan Williams's message of "Mon, 7 May 2018 11:57:10 -0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: 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 Dan Williams writes: > On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox wro= te: >> 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, ker= nel 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=E2=80=99s classical features like the buddy >>> 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? 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