Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751945AbbEGToV (ORCPT ); Thu, 7 May 2015 15:44:21 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:36238 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751050AbbEGToS (ORCPT ); Thu, 7 May 2015 15:44:18 -0400 MIME-Version: 1.0 In-Reply-To: <20150507184037.GA22952@gmail.com> References: <20150506200219.40425.74411.stgit@dwillia2-desk3.amr.corp.intel.com> <20150507161807.GA1671@lst.de> <20150507184037.GA22952@gmail.com> Date: Thu, 7 May 2015 12:44:17 -0700 Message-ID: Subject: Re: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn_t From: Dan Williams To: Ingo Molnar 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1862 Lines: 38 On Thu, May 7, 2015 at 11:40 AM, Ingo Molnar wrote: > > * 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. True, that's more "dm-cache" than "RAID accelerator", but point taken. -- 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/