lkml.org 
[lkml]   [2008]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 11 of 11] x86: defer cr3 reload when doing pud_clear()
Keir Fraser wrote:
> Go read the Intel application note "TLBs, Paging-Structure Caches, and Their
> Invalidation" at http://www.intel.com/design/processor/applnots/317080.pdf
>
> Section 8.1 explains about the PDPTR cache in 32-bit PAE mode, which can
> only be refreshed by appropriate tickling of CR0, CR3 or CR4.
>

Yeah, I found that document, and mentioned it a little lower in the mail ;)

> It is also important to note that *any* valid page directory entry at *any*
> level in the page-table hierarchy can become cached at *any* time. Basically
> TLB lookup is performed as a longest-prefix match on the linear address to
> skip as many levels in a page-table walk as possible (where a walk is
> needed, because there is no full-length match on the linear address). So, if
> you modify a directory entry from present to not-present, or change the page
> directory that a valid pde points to, you probably need to flush the pde
> caching structure. One piece of good news is that all pde caches are flushed
> by any arbitrary INVLPG.
>

Hm, but then chapter 10 goes and makes things confusing with
"Alternative INVLPG Behavior"; but I guess if software needs to
explicitly enable this behaviour in a yet-to-be-determined way, its OK...

Is there any guide about the tradeoff of when to use invlpg vs flushing
the whole tlb? 1 page? 10? 90% of the tlb?

J


\
 
 \ /
  Last update: 2008-01-26 00:47    [W:0.052 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site