lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 8 May 2015 16:40:35 -0400
From:	"John Stoffel" <john@...ffel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	John Stoffel <john@...ffel.org>, Ingo Molnar <mingo@...nel.org>,
	Rik van Riel <riel@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Boaz Harrosh <boaz@...xistor.com>, Jan Kara <jack@...e.cz>,
	Mike Snitzer <snitzer@...hat.com>, Neil Brown <neilb@...e.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Chris Mason <clm@...com>, Paul Mackerras <paulus@...ba.org>,
	"H. Peter Anvin" <hpa@...or.com>, Christoph Hellwig <hch@....de>,
	Alasdair Kergon <agk@...hat.com>,
	"linux-nvdimm\@lists.01.org" <linux-nvdimm@...1.01.org>,
	Mel Gorman <mgorman@...e.de>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Jens Axboe <axboe@...nel.dk>, "Theodore Ts'o" <tytso@....edu>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Julia Lawall <Julia.Lawall@...6.fr>, Tejun Heo <tj@...nel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 00/10] evacuate struct page from the block layer,
 introduce __pfn_t

>>>>> "Linus" == Linus Torvalds <torvalds@...ux-foundation.org> writes:

Linus> On Fri, May 8, 2015 at 7:40 AM, John Stoffel <john@...ffel.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists