Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751906AbbEGRbK (ORCPT ); Thu, 7 May 2015 13:31:10 -0400 Received: from mail-qg0-f45.google.com ([209.85.192.45]:36629 "EHLO mail-qg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394AbbEGRbI (ORCPT ); Thu, 7 May 2015 13:31:08 -0400 Date: Thu, 7 May 2015 13:30:58 -0400 From: Jerome Glisse To: Christoph Hellwig Cc: Linus Torvalds , Dan Williams , Linux Kernel Mailing List , Boaz Harrosh , Jan Kara , Mike Snitzer , Neil Brown , Benjamin Herrenschmidt , Dave Hansen , Heiko Carstens , Chris Mason , Paul Mackerras , "H. Peter Anvin" , Alasdair Kergon , "linux-nvdimm@lists.01.org" , Ingo Molnar , Mel Gorman , Matthew Wilcox , Ross Zwisler , Rik van Riel , Martin Schwidefsky , Jens Axboe , "Theodore Ts'o" , "Martin K. Petersen" , Julia Lawall , Tejun Heo , linux-fsdevel , Andrew Morton , "Paul E. McKenney" Subject: Re: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn_t Message-ID: <20150507173057.GA5966@gmail.com> References: <20150506200219.40425.74411.stgit@dwillia2-desk3.amr.corp.intel.com> <20150507161807.GA1671@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150507161807.GA1671@lst.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2212 Lines: 43 On Thu, May 07, 2015 at 06:18:07PM +0200, Christoph Hellwig wrote: > On Wed, May 06, 2015 at 05:19:48PM -0700, Linus Torvalds wrote: > > What is the primary thing that is driving this need? Do we have a very > > concrete example? > > FYI, I plan to to implement RAID acceleration using nvdimms, and I plan to > ue pages for that. The code just merge for 4.1 can easily support page > backing, and I plan to use that for now. This still leaves support > for the gigantic intel nvdimms discovered over EFI out, but given that > I don't have access to them, and I dont know of any publically available > there's little I can do for now. But adding on demand allocate struct > pages for the seems like the easiest way forward. Boaz already has > code to allocate pages for them, although not on demand but at boot / plug in > time. I think here other folks might be interested, i am ccing Paul. But for GPU we are facing similar issue of trying to present the GPU memory to the kernel in a coherent way (coherent from the design and linux kernel concept POV). For this dynamicaly allocated struct page might effectively be a solution that could be share btw persistent memory and GPU folks. We can even enforce thing like VMEMMAP and have special region carveout where we can dynamicly map/unmap backing page for range of device pfn. This would also allow to catch people trying to access such page, we could add a set of new helper like : get_page_dev()/put_page_dev() ... and only the _dev version would works on this new kind of memory, regular get_page()/put_page() would throw error. This should allow to make sure only legitimate users are referencing such page. Issue might be that we can run out of kernel address space with 48bits but if such monstruous computer ever see the light of day they might consider using CPU with more bits. Another issue is that we might care for the 32bits platform too, but that's solvable at a small cost. Cheers, J?r?me -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/