From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John Stoffel" Subject: Re: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn_t Date: Fri, 8 May 2015 16:40:35 -0400 Message-ID: <21837.8003.575817.928310@quad.stoffel.home> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org >>>>> "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