[lkml]   [2002]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Lse-tech] Re: 10.31 second kernel compile
On Sat, Mar 16, 2002 at 12:57:11PM -0700, 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.263 / U:0.528 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site