Messages in this thread | | | Subject | Re: increased translation cache footprint in v2.6 | From | Benjamin Herrenschmidt <> | Date | Mon, 27 Jun 2005 11:55:24 +1000 |
| |
On Sun, 2005-06-26 at 17:33 -0700, David S. Miller wrote: > From: Marcelo Tosatti <marcelo.tosatti@cyclades.com> > Date: Sun, 26 Jun 2005 15:52:10 -0300 > > > Well, a TLB entry might cache different sized pages. The platform > > support 4kb, 16kb and 8Mb (IIRC, maybe some other size also). The > > bigger pages (8Mb) are only used to map 8Mbytes of instruction at > > KERNELBASE, 24Mbytes of data (3 8Mbyte entries) also at KERNELBASE > > and another 8Mbytes of the configuration registers memory space, > > which lives outside RAM space. > > Why don't you use 8MB TLB entries when there is a miss to > one of the PAGE_OFFSET pages? I'm not saying to lock them, > just to use large 8MB TLB entries when a miss is taken for > kernel data accesses to where the kernel maps all of lowmem.
Looks like the right thing to do indeed. Should be fairly easy, just test if the address if negative (you'll never use >2Gb address space on these) and ... heh, you already do it in your 8xx TLB miss handlers to separate user page tables from kernel page tables :) So I doubt the normal user TLB miss path will be any different and the kernel TLB miss path though be separate and faster due to having much less misses.
Also, you may want to bump the whole page size to 64k on these, interesting exercise but probably not very difficult. Our ABI is already clean at the userland level for up to 64k. We did some experiments on ppc64 with pseudo-64k pages (emulating them in software) and common ppc32 userland is just fine.
Using a larger page size makes a lot of sense of those embedded CPUs with small TLBs where you usually don't use much or no swap at all.
Ben.
- 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/
| |