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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17969.59676.356383.189020@cargo.ozlabs.ibm.com>
Date:	Fri, 27 Apr 2007 22:14:20 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
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

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.

It's not as simple on 64-bit powerpc with the hash table of course,
because the page size is chosen at the segment (256MB) level,
restricting where we can put 64k and 16M pages to some degree.

> 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.

Paul.
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ