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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
