Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753307AbbEHUmR (ORCPT ); Fri, 8 May 2015 16:42:17 -0400 Received: from mailrelay.lanline.com ([216.187.10.16]:38276 "EHLO mailrelay.lanline.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752809AbbEHUmM (ORCPT ); Fri, 8 May 2015 16:42:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21837.8003.575817.928310@quad.stoffel.home> Date: Fri, 8 May 2015 16:40:35 -0400 From: "John Stoffel" To: Linus Torvalds Cc: John Stoffel , Ingo Molnar , Rik van Riel , Dave Hansen , Dan Williams , 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 In-Reply-To: References: <20150507173641.GA21781@gmail.com> <554BA748.9030804@linux.intel.com> <20150507191107.GB22952@gmail.com> <554CBE17.4070904@redhat.com> <20150508140556.GA2185@gmail.com> <21836.51957.715473.780762@quad.stoffel.home> X-Mailer: VM 8.2.0b under 23.4.1 (x86_64-pc-linux-gnu) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2402 Lines: 55 >>>>> "Linus" == Linus Torvalds writes: Linus> On Fri, May 8, 2015 at 7:40 AM, John Stoffel wrote: >> >> Now go and look at your /home or /data/ or /work areas, where the >> endusers are actually keeping their day to day work. Photos, mp3, >> design files, source code, object code littered around, etc. Linus> However, the big files in that list are almost immaterial from a Linus> caching standpoint. Linus> Caching source code is a big deal - just try not doing it and Linus> you'll figure it out. And the kernel C source files used to Linus> have a median size around 4k. Caching any files is a big deal, and if I'm doing batch edits of large jpegs, won't they get cached as well? Linus> The big files in your home directory? Let me make an educated Linus> guess. Very few to *none* of them are actually in your page Linus> cache right now. And you'd never even care if they ever made Linus> it into your page cache *at*all*. Much less whether you could Linus> ever cache them using large pages using some very fancy cache. Hmm... probably not honestly, since I'm not a home and not using the system actively right now. But I can see situations where being able to mix different page sizes efficiently might be a good thing. Linus> There are big files that care about caches, but they tend to be Linus> binaries, and for other reasons (things like randomization) you Linus> would never want to use largepages for those anyway. Or large design files, like my users at $WORK use, which can be 4Gb in size for a large design, which is ASIC chip layout work. So I'm a little bit in the minority there. And yes I do have other users will millions of itty bitty files as well. Linus> So from a page cache standpoint, I think the 4kB size still Linus> matters. A *lot*. largepages are a complete red herring, and Linus> will continue to be so pretty much forever (anonymous Linus> largepages perhaps less so). I think in the future, being able to efficiently mix page sizes will become useful, if only to lower the memory overhead of keeping track of large numbers of pages. John -- 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/