Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753186AbbEHOGG (ORCPT ); Fri, 8 May 2015 10:06:06 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:36853 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752800AbbEHOGD (ORCPT ); Fri, 8 May 2015 10:06:03 -0400 Date: Fri, 8 May 2015 16:05:56 +0200 From: Ingo Molnar To: Rik van Riel Cc: Dave Hansen , Dan Williams , Linus Torvalds , Linux Kernel Mailing List , Boaz Harrosh , Jan Kara , Mike Snitzer , Neil Brown , Benjamin Herrenschmidt , Heiko Carstens , Chris Mason , Paul Mackerras , "H. Peter Anvin" , Christoph Hellwig , Alasdair Kergon , "linux-nvdimm@lists.01.org" , Mel Gorman , Matthew Wilcox , Ross Zwisler , 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: <20150508140556.GA2185@gmail.com> References: <20150507173641.GA21781@gmail.com> <554BA748.9030804@linux.intel.com> <20150507191107.GB22952@gmail.com> <554CBE17.4070904@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554CBE17.4070904@redhat.com> 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: 1887 Lines: 46 * Rik van Riel wrote: > The disadvantage is pretty obvious too: 4kB pages would no longer be > the fast case, with an indirection. I do not know how much of an > issue that would be, or whether it even makes sense for 4kB pages to > continue being the fast case going forward. I strongly disagree that 4kB does not matter as much: it is _the_ bread and butter of 99% of Linux usecases. 4kB isn't going away anytime soon - THP might look nice in benchmarks, but it does not matter nearly as much in practice and for filesystems and IO it's absolutely crazy to think about 2MB granularity. Having said that, I don't think a single jump of indirection is a big issue - except for the present case where all the pmem IO space is mapped non-cacheable. Write-through caching patches are in the works though, and that should make it plenty fast. > Memory trends point in one direction, file size trends in another. > > For persistent memory, we would not need 4kB page struct pages > unless memory from a particular area was in small files AND those > files were being actively accessed. [...] Average file size on my system's /usr is 12.5K: triton:/usr> ( echo -n $(echo $(find . -type f -printf "%s\n") | sed 's/ /+/g' | bc); echo -n "/"; find . -type f -printf "%s\n" | wc -l; ) | bc 12502 > [...] Large files (mapped in 2MB chunks) or inactive small files > would not need the 4kB page structs around. ... they are the utter uncommon case. 4K is here to stay, and for a very long time - until humans use computers I suspect. But I don't think the 2MB metadata chunking is wrong per se. 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/