Message-ID: <21836.51957.715473.780762@quad.stoffel.home>
Date:	Fri, 8 May 2015 10:40:53 -0400
From:	"John Stoffel" <john@...ffel.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Rik van Riel <riel@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

>>>>> "Ingo" == Ingo Molnar <mingo@...nel.org> writes:

Ingo> * Rik van Riel <riel@...hat.com> 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.

Ingo> I strongly disagree that 4kB does not matter as much: it is _the_ 
Ingo> bread and butter of 99% of Linux usecases. 4kB isn't going away 
Ingo> anytime soon - THP might look nice in benchmarks, but it does not 
Ingo> matter nearly as much in practice and for filesystems and IO it's 
Ingo> absolutely crazy to think about 2MB granularity.

Ingo> Having said that, I don't think a single jump of indirection is a big 
Ingo> issue - except for the present case where all the pmem IO space is 
Ingo> mapped non-cacheable. Write-through caching patches are in the works 
Ingo> 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. [...]

Ingo> Average file size on my system's /usr is 12.5K:

Ingo> triton:/usr> ( echo -n $(echo $(find . -type f -printf "%s\n") |
Ingo> sed 's/ /+/g' | bc); echo -n "/"; find . -type f -printf "%s\n"
Ingo> | wc -l; ) | bc 12502

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.

Now I also have 12Tb filesystems with 30+ million files in them, which
just *suck* for backup, esp incrementals.  I have one monster with 85+
million files (time to get beat on users again ...) which needs to be
pruned.

So I'm not arguing against you, I'm just saying you need better more
representative numbers across more day to day work.  Running this
exact same command against my home directory gets:

528989

So I'm not arguing one way or another... just providing numbers.
--
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