Re: [PATCH 11 of 11] x86: defer cr3 reload when doing pud_clear()

[Jeremy Fitzhardinge <jeremy@goop.org>]

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