From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E13421A1DF7 for ; Fri, 20 May 2016 00:58:43 -0700 (PDT) Date: Fri, 20 May 2016 09:58:33 +0200 From: Johannes Thumshirn Subject: Re: [PATCH v3 3/5] /dev/dax, core: file operations and dax-mmap Message-ID: <20160520075833.GF4413@c203.arch.suse.de> References: <146360496572.37439.6497663679891935585.stgit@dwillia2-desk3.amr.corp.intel.com> <146360498206.37439.343951904240579439.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <146360498206.37439.343951904240579439.stgit@dwillia2-desk3.amr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: linux-nvdimm@lists.01.org, Dave Hansen , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, Hannes Reinecke , Andrew Morton , "Paul E. McKenney" , hch@lst.de List-ID: On Wed, May 18, 2016 at 01:56:22PM -0700, Dan Williams wrote: > The "Device DAX" core enables dax mappings of performance / feature > differentiated memory. An open mapping or file handle keeps the backing > struct device live, but new mappings are only possible while the device > is enabled. Faults are handled under rcu_read_lock to synchronize > with the enabled state of the device. > = > Similar to the filesystem-dax case the backing memory may optionally > have struct page entries. However, unlike fs-dax there is no support > for private mappings, or mappings that are not backed by media (see > use of zero-page in fs-dax). > = > Mappings are always guaranteed to match the alignment of the dax_region. > If the dax_region is configured to have a 2MB alignment, all mappings > are guaranteed to be backed by a pmd entry. Contrast this determinism > with the fs-dax case where pmd mappings are opportunistic. If userspace > attempts to force a misaligned mapping, the driver will fail the mmap > attempt. See dax_dev_check_vma() for other scenarios that are rejected, > like MAP_PRIVATE mappings. > = > Cc: Hannes Reinecke > Cc: Jeff Moyer > Cc: Christoph Hellwig > Cc: Andrew Morton > Cc: Dave Hansen > Cc: Ross Zwisler > Acked-by: "Paul E. McKenney" > Signed-off-by: Dan Williams OK from my side, Reviewed-by: Johannes Thumshirn -- = Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton HRB 21284 (AG N=FCrnberg) Key fingerprint =3D EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:50778 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754463AbcETH6h (ORCPT ); Fri, 20 May 2016 03:58:37 -0400 Date: Fri, 20 May 2016 09:58:33 +0200 From: Johannes Thumshirn To: Dan Williams Cc: linux-nvdimm@lists.01.org, Dave Hansen , linux-kernel@vger.kernel.org, hch@lst.de, linux-block@vger.kernel.org, Hannes Reinecke , Andrew Morton , "Paul E. McKenney" Subject: Re: [PATCH v3 3/5] /dev/dax, core: file operations and dax-mmap Message-ID: <20160520075833.GF4413@c203.arch.suse.de> References: <146360496572.37439.6497663679891935585.stgit@dwillia2-desk3.amr.corp.intel.com> <146360498206.37439.343951904240579439.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: <146360498206.37439.343951904240579439.stgit@dwillia2-desk3.amr.corp.intel.com> Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org On Wed, May 18, 2016 at 01:56:22PM -0700, Dan Williams wrote: > The "Device DAX" core enables dax mappings of performance / feature > differentiated memory. An open mapping or file handle keeps the backing > struct device live, but new mappings are only possible while the device > is enabled. Faults are handled under rcu_read_lock to synchronize > with the enabled state of the device. > > Similar to the filesystem-dax case the backing memory may optionally > have struct page entries. However, unlike fs-dax there is no support > for private mappings, or mappings that are not backed by media (see > use of zero-page in fs-dax). > > Mappings are always guaranteed to match the alignment of the dax_region. > If the dax_region is configured to have a 2MB alignment, all mappings > are guaranteed to be backed by a pmd entry. Contrast this determinism > with the fs-dax case where pmd mappings are opportunistic. If userspace > attempts to force a misaligned mapping, the driver will fail the mmap > attempt. See dax_dev_check_vma() for other scenarios that are rejected, > like MAP_PRIVATE mappings. > > Cc: Hannes Reinecke > Cc: Jeff Moyer > Cc: Christoph Hellwig > Cc: Andrew Morton > Cc: Dave Hansen > Cc: Ross Zwisler > Acked-by: "Paul E. McKenney" > Signed-off-by: Dan Williams OK from my side, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N�rnberg GF: Felix Imend�rffer, Jane Smithard, Graham Norton HRB 21284 (AG N�rnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755723AbcETH6j (ORCPT ); Fri, 20 May 2016 03:58:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:50778 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754463AbcETH6h (ORCPT ); Fri, 20 May 2016 03:58:37 -0400 Date: Fri, 20 May 2016 09:58:33 +0200 From: Johannes Thumshirn To: Dan Williams Cc: linux-nvdimm@ml01.01.org, Dave Hansen , linux-kernel@vger.kernel.org, hch@lst.de, linux-block@vger.kernel.org, Hannes Reinecke , Andrew Morton , "Paul E. McKenney" Subject: Re: [PATCH v3 3/5] /dev/dax, core: file operations and dax-mmap Message-ID: <20160520075833.GF4413@c203.arch.suse.de> References: <146360496572.37439.6497663679891935585.stgit@dwillia2-desk3.amr.corp.intel.com> <146360498206.37439.343951904240579439.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <146360498206.37439.343951904240579439.stgit@dwillia2-desk3.amr.corp.intel.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 18, 2016 at 01:56:22PM -0700, Dan Williams wrote: > The "Device DAX" core enables dax mappings of performance / feature > differentiated memory. An open mapping or file handle keeps the backing > struct device live, but new mappings are only possible while the device > is enabled. Faults are handled under rcu_read_lock to synchronize > with the enabled state of the device. > > Similar to the filesystem-dax case the backing memory may optionally > have struct page entries. However, unlike fs-dax there is no support > for private mappings, or mappings that are not backed by media (see > use of zero-page in fs-dax). > > Mappings are always guaranteed to match the alignment of the dax_region. > If the dax_region is configured to have a 2MB alignment, all mappings > are guaranteed to be backed by a pmd entry. Contrast this determinism > with the fs-dax case where pmd mappings are opportunistic. If userspace > attempts to force a misaligned mapping, the driver will fail the mmap > attempt. See dax_dev_check_vma() for other scenarios that are rejected, > like MAP_PRIVATE mappings. > > Cc: Hannes Reinecke > Cc: Jeff Moyer > Cc: Christoph Hellwig > Cc: Andrew Morton > Cc: Dave Hansen > Cc: Ross Zwisler > Acked-by: "Paul E. McKenney" > Signed-off-by: Dan Williams OK from my side, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850