On Tue, Oct 14, 2003 at 11:47:59AM +0200, Maciej W. Rozycki wrote: > > Log message: > > Config bits of support for TLB page sizes other than 4k. So not > > functional yet but this is a fairly large project and everybody should > > finally get rid of the assumption that PAGE_SIZE is always 4k. > > I've already thought we might unconditionally switch to a larger page > size, e.g. 16kB, for the 64-bit kernel -- I suppose everything that > supports 64-bit operation also supports larger page sizes, doesn't it? True. At 16k pagesize we can also start harvesting other advantages, for example we'd then know that cpu_has_dc_aliases is never true which will make the compiler simply throw away large parts of the cache code. As the result of living in an alias-free universe we could use the nice recursive page fault technique from very old Linux kernels again, something that allowed blindigly fast TLB refill handlers. An additional bonus is the increased coverage of a pagetables with 16k page size. A 16k page has space for 2048 pointers. So in case of a two level pagetable tree that makes the total capacity 16k*2k*2k = 64GB. So that means one level of the pagetable tree less than we currently have, yet enough capacity for everything but the largest jobs. Still want more? A 3 level tree would then cover 128TB of virtual address space already exceedin the hardware limits of all processors but the R8000. 64k pagesize stretches the limits even further. Here a two level pagetable tree would cover 4TB, 3-level could cover 32PB exceeding the capacity of every MIPS processor ever made - and probably sufficient for the coming decade :-) Ralf
