Messages in this thread | | | Date | Sat, 16 Mar 2002 21:05:04 +0100 | From | Andi Kleen <> | Subject | Re: [Lse-tech] Re: 10.31 second kernel compile |
| |
On Sat, Mar 16, 2002 at 12:57:11PM -0700, yodaiken@fsmlabs.com wrote: > On Sat, Mar 16, 2002 at 08:32:26PM +0100, Andi Kleen wrote: > > x86-64 aka AMD Hammer does hardware (or more likely microcode) search of > > page tables. > > It has a 4 level page table with 4K pages. Generic Linux MM code only sees > > the first slot in 4th level page limit user space to 512GB with 3 levels. > > What about 2M pages?
They are not supported for user space, but used in private mappings for kernel text and direct memory mappings. Generic code never sees them.
That will hopefully change eventually because 2M pages are a bit help for a lot of applications that are limited by TLB thrashing, but needs some thinking on how to avoid the fragmentation trap (e.g. I'm considering to add a highmem zone again just for that and use rmap with targetted physical freeing to allocating them)
> > > Direct mappings and kernel mappings are handled specially by architecture > > specific code outside that first slot. > > > > The CPU itself has I/D TLBs split into L1 and L2. > > There was something in some AMD doc about preventing tlbflush on process > switch - through a context like thing perhaps? Any idea?
There are global pages which are normally not flushed over context switch. That is used for all kernel mappings.
There is also some optimization in the CPU that tries to do a selective flush only when you reload CR3, but as far as I can see doesn't help for the Linux context switch. It only works around broken TLB flushing algorithms in some Windows version.
-Andi - 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/
| |