Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751378AbbEGSkq (ORCPT ); Thu, 7 May 2015 14:40:46 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:33088 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750986AbbEGSkn (ORCPT ); Thu, 7 May 2015 14:40:43 -0400 Date: Thu, 7 May 2015 20:40:37 +0200 From: Ingo Molnar To: Dan Williams Cc: Christoph Hellwig , Linus Torvalds , 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" , 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 Subject: Re: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn_t Message-ID: <20150507184037.GA22952@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=us-ascii Content-Disposition: inline In-Reply-To: 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: 1913 Lines: 43 * Dan Williams wrote: > On Thu, May 7, 2015 at 9:18 AM, 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. > > Hmmm, the capacities of persistent memory that would be assigned for > a raid accelerator would be limited by diminishing returns. I.e. > there seems to be no point to assign more than 8GB or so to the > cache? [...] Why would that be the case? If it's not a temporary cache but a persistent cache that hosts all the data even after writeback completes then going to huge sizes will bring similar benefits to using a large, fast SSD disk on your desktop... The larger, the better. And it also persists across reboots. It could also host the RAID write intent bitmap (the dirty stripes/chunks bitmap) for extra speedups. (This bitmap is pretty small, but important to speed up resyncs after crashes or power loss.) Thanks, Ingo -- 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/