From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934335AbcLLRPi (ORCPT ); Mon, 12 Dec 2016 12:15:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8431 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753752AbcLLRPE (ORCPT ); Mon, 12 Dec 2016 12:15:04 -0500 From: Jeff Moyer To: Dan Williams Cc: linux-nvdimm@ml01.01.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/8] device-dax: sub-division support References: <148143770485.10950.13227732273892953675.stgit@dwillia2-desk3.amr.corp.intel.com> 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, 12 Dec 2016 12:15:02 -0500 In-Reply-To: <148143770485.10950.13227732273892953675.stgit@dwillia2-desk3.amr.corp.intel.com> (Dan Williams's message of "Sat, 10 Dec 2016 22:28:25 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 12 Dec 2016 17:15:04 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Dan, Dan Williams writes: >>>From [PATCH 6/8] dax: sub-division support: > > Device-DAX is a mechanism to establish mappings of performance / feature > differentiated memory with strict fault behavior guarantees. With > sub-division support a platform owner can provision sub-allocations of a > dax-region into separate devices. The provisioning mechanism follows the > same scheme as the libnvdimm sub-system in that a 'seed' device is > created at initialization time that can be resized from zero to become > enabled. > > Unlike the nvdimm sub-system there is no on media labelling scheme > associated with this partitioning. Provisioning decisions are ephemeral > / not automatically restored after reboot. While the initial use case of > device-dax is persistent memory other uses case may be volatile, so the > device-dax core is unable to assume the underlying memory is pmem. The > task of recalling a partitioning scheme or permissions on the device(s) > is left to userspace. Can you explain this reasoning in a bit more detail, please? If you have specific use cases in mind, that would be helpful. > For persistent allocations, naming, and permissions automatically > recalled by the kernel, use filesystem-DAX. For a userspace helper I'd agree with that guidance if it wasn't for the fact that device dax was born out of the need to be able to flush dirty data in a safe manner from userspace. At best, we're giving mixed guidance to application developers. -Jeff > library and utility for manipulating device-dax instances see libdaxctl > and the daxctl utility here: https://github.com/pmem/ndctl > > --- > > Dan Williams (8): > dax: add region-available-size attribute > dax: add region 'id', 'size', and 'align' attributes > dax: register seed device > dax: use multi-order radix for resource lookup > dax: refactor locking out of size calculation routines > dax: sub-division support > dax: add / remove dax devices after provisioning > dax: add debug for region available_size > > > drivers/dax/Kconfig | 1 > drivers/dax/dax.c | 747 ++++++++++++++++++++++++++++++++++++++++++++++++--- > 2 files changed, 698 insertions(+), 50 deletions(-) > _______________________________________________ > Linux-nvdimm mailing list > Linux-nvdimm@lists.01.org > https://lists.01.org/mailman/listinfo/linux-nvdimm