From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5EFF5202E617C for ; Sat, 21 Oct 2017 01:12:17 -0700 (PDT) Date: Sat, 21 Oct 2017 10:15:56 +0200 From: Christoph Hellwig Subject: Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax Message-ID: <20171021081556.GC21101@lst.de> References: <150846713528.24336.4459262264611579791.stgit@dwillia2-desk3.amr.corp.intel.com> <150846714747.24336.14704246566580871364.stgit@dwillia2-desk3.amr.corp.intel.com> <20171020075735.GA14378@lst.de> <20171020162933.GA26320@lst.de> <20171021032008.GA27694@bombadil.infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Jan Kara , "linux-nvdimm@lists.01.org" , Benjamin Herrenschmidt , Heiko Carstens , "linux-kernel@vger.kernel.org" , Matthew Wilcox , linux-xfs@vger.kernel.org, Linux MM , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , linux-fsdevel , Andrew Morton , Christoph Hellwig , Gerald Schaefer List-ID: On Fri, Oct 20, 2017 at 09:16:21PM -0700, Dan Williams wrote: > > For example, I think it's entirely sensible to support ->direct_access > > for RAID-0. Dell are looking at various different options for having > > one pmemX device per DIMM and using RAID to lash them together. > > ->direct_access makes no sense for RAID-5 or RAID-1, but RAID-0 makes > > sense to me. > > > > Last time we tried to take sleeping out, there were grumblings from people > > with network block devices who thought they'd want to bring pages in > > across the network. I'm a bit less sympathetic to this because I don't > > know anyone actively working on it, but the RAID-0 case is something I > > think we should care about. > > True, good point. In fact we already support device-mapper striping > with ->direct_access(). I'd still like to go ahead with the sleeping > removal. When those folks come back and add network direct_access they > can do the hard work of figuring out cases where we need to call > direct_access in atomic contexts. It would be great to move DAX striping out of DM so that we don't need to keep fake block devices around just for that. In fact if Dell is so interested in it it would be great if they get a strip/concact table into ACPI so that the bios and OS can agree on it in a standardized way, and we can just implement it in the nvdimm layer. I agree that there is no reason at all to support sleeping in ->direct_access - it makes life painful for no gain at all. If you network access remote memory you will need local memory to support mmap, so we might as well use the page cache instead of reinventing it. (saying that with my remote pmem over NFS hat on). _______________________________________________ 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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753136AbdJUIQA (ORCPT ); Sat, 21 Oct 2017 04:16:00 -0400 Received: from verein.lst.de ([213.95.11.211]:52352 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751773AbdJUIP6 (ORCPT ); Sat, 21 Oct 2017 04:15:58 -0400 Date: Sat, 21 Oct 2017 10:15:56 +0200 From: Christoph Hellwig To: Dan Williams Cc: Matthew Wilcox , Christoph Hellwig , Andrew Morton , Jan Kara , "linux-nvdimm@lists.01.org" , Benjamin Herrenschmidt , Heiko Carstens , "linux-kernel@vger.kernel.org" , linux-xfs@vger.kernel.org, Linux MM , Jeff Moyer , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , linux-fsdevel , Ross Zwisler , Gerald Schaefer Subject: Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax Message-ID: <20171021081556.GC21101@lst.de> References: <150846713528.24336.4459262264611579791.stgit@dwillia2-desk3.amr.corp.intel.com> <150846714747.24336.14704246566580871364.stgit@dwillia2-desk3.amr.corp.intel.com> <20171020075735.GA14378@lst.de> <20171020162933.GA26320@lst.de> <20171021032008.GA27694@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 20, 2017 at 09:16:21PM -0700, Dan Williams wrote: > > For example, I think it's entirely sensible to support ->direct_access > > for RAID-0. Dell are looking at various different options for having > > one pmemX device per DIMM and using RAID to lash them together. > > ->direct_access makes no sense for RAID-5 or RAID-1, but RAID-0 makes > > sense to me. > > > > Last time we tried to take sleeping out, there were grumblings from people > > with network block devices who thought they'd want to bring pages in > > across the network. I'm a bit less sympathetic to this because I don't > > know anyone actively working on it, but the RAID-0 case is something I > > think we should care about. > > True, good point. In fact we already support device-mapper striping > with ->direct_access(). I'd still like to go ahead with the sleeping > removal. When those folks come back and add network direct_access they > can do the hard work of figuring out cases where we need to call > direct_access in atomic contexts. It would be great to move DAX striping out of DM so that we don't need to keep fake block devices around just for that. In fact if Dell is so interested in it it would be great if they get a strip/concact table into ACPI so that the bios and OS can agree on it in a standardized way, and we can just implement it in the nvdimm layer. I agree that there is no reason at all to support sleeping in ->direct_access - it makes life painful for no gain at all. If you network access remote memory you will need local memory to support mmap, so we might as well use the page cache instead of reinventing it. (saying that with my remote pmem over NFS hat on). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 21 Oct 2017 10:15:56 +0200 From: Christoph Hellwig To: Dan Williams Cc: Matthew Wilcox , Christoph Hellwig , Andrew Morton , Jan Kara , "linux-nvdimm@lists.01.org" , Benjamin Herrenschmidt , Heiko Carstens , "linux-kernel@vger.kernel.org" , linux-xfs@vger.kernel.org, Linux MM , Jeff Moyer , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , linux-fsdevel , Ross Zwisler , Gerald Schaefer Subject: Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax Message-ID: <20171021081556.GC21101@lst.de> References: <150846713528.24336.4459262264611579791.stgit@dwillia2-desk3.amr.corp.intel.com> <150846714747.24336.14704246566580871364.stgit@dwillia2-desk3.amr.corp.intel.com> <20171020075735.GA14378@lst.de> <20171020162933.GA26320@lst.de> <20171021032008.GA27694@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: On Fri, Oct 20, 2017 at 09:16:21PM -0700, Dan Williams wrote: > > For example, I think it's entirely sensible to support ->direct_access > > for RAID-0. Dell are looking at various different options for having > > one pmemX device per DIMM and using RAID to lash them together. > > ->direct_access makes no sense for RAID-5 or RAID-1, but RAID-0 makes > > sense to me. > > > > Last time we tried to take sleeping out, there were grumblings from people > > with network block devices who thought they'd want to bring pages in > > across the network. I'm a bit less sympathetic to this because I don't > > know anyone actively working on it, but the RAID-0 case is something I > > think we should care about. > > True, good point. In fact we already support device-mapper striping > with ->direct_access(). I'd still like to go ahead with the sleeping > removal. When those folks come back and add network direct_access they > can do the hard work of figuring out cases where we need to call > direct_access in atomic contexts. It would be great to move DAX striping out of DM so that we don't need to keep fake block devices around just for that. In fact if Dell is so interested in it it would be great if they get a strip/concact table into ACPI so that the bios and OS can agree on it in a standardized way, and we can just implement it in the nvdimm layer. I agree that there is no reason at all to support sleeping in ->direct_access - it makes life painful for no gain at all. If you network access remote memory you will need local memory to support mmap, so we might as well use the page cache instead of reinventing it. (saying that with my remote pmem over NFS hat on). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org