Nick Piggin writes:

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

quoted text
> 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.
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/