linux-kernel - Re: [00/17] Large Blocksize Support V3

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, 27 Apr 2007 22:36:07 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Paul Mackerras <paulus@...ba.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <clameter@....com>,
	David Chinner <dgc@....com>, linux-kernel@...r.kernel.org,
	Mel Gorman <mel@...net.ie>,
	William Lee Irwin III <wli@...omorphy.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Badari Pulavarty <pbadari@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [00/17] Large Blocksize Support V3

Paul Mackerras wrote:
> Nick Piggin writes:
> 
> 
>>For the TLB issue, higher order pagecache doesn't help. If distros
> 
> 
> Oh?  Assuming your hardware is capable of supporting a variety of page
> sizes, and of putting a page at any address that is a multiple of its
> size, it should help, potentially a great deal, as far as I can see.
> I'm thinking in particular of machines that have software-loaded
> fully-associative TLBs and support a lot of page sizes, e.g.
> 4kB * 4^n for n = 0 up to 8 or so, like some embedded powerpc chips.

That's a little bit more than just the higher order pagecache patch.
But I don't know if that would be impossible to do with the "attempt
to allocate contiguous pagecache" approach either. Or if it would be
worthwhile to support.


>>ship with a 4K page size on powerpc, and use some larger pages in
>>the pagecache, some people are still going to get angry because
>>they wanted to use 64K pages... But I agree 64K pages is too big
>>for most things anyway, and 16 would be better as a default (which
>>hopefully x86-64 will get one day).
> 
> 
> Even 16k is going to bloat the page cache, and some people will
> complain.  One way that x86-64 could do 16k pages is by still indexing
> the PTE page in units of 4k, but then have an indicator in the PTE
> that this is a 16k page.  Thus a 16k page would occupy 4 consecutive
> PTEs, but once it was loaded into the TLB, a single TLB entry would
> map the whole 16k.  That would give the expanded TLB reach and allow
> 4k and 16k pages to be intermixed freely.

I guess any page size bloats the pagecache relative to something
smaller :) But 4K doesn't seem to be proving too much problem for
x86 and I'm not talking about an actual implementation coming up,
but just a size that would make sense in future (and probably last
for a long time).

-- 
SUSE Labs, Novell Inc.
-
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/