Messages in this thread | | | Date | Fri, 25 Jan 2008 16:20:27 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 11 of 11] x86: defer cr3 reload when doing pud_clear() |
| |
Ingo Molnar wrote: > * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > >> Is there any guide about the tradeoff of when to use invlpg vs >> flushing the whole tlb? 1 page? 10? 90% of the tlb? > > i made measurements some time ago and INVLPG was quite uniformly slow on > all important CPU types - on the order of 100+ cycles. It's probably > microcode. With a cr3 flush being on the order of 200-300 cycles (plus > any add-on TLB miss costs - but those are amortized quite well as long > as the pagetables are well cached - which they usually are on today's > 2MB-ish L2 caches), the high cost of INVLPG rarely makes it worthwile > for anything more than a few pages. > > so INVLPG makes sense for pagetable fault realated single-address > flushes, but they rarely make sense for range flushes. (and that's how > Linux uses it) >
Incidentally, as far as I can tell, the main INVLPG is so slow is because of its painful behaviour with regards to large pages which may have been split by hardware.
-hpa
| |