* Jeremy Fitzhardinge <jeremy@goop.org> wrote: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) Ingo --
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Willy Tarreau | Re: Linux 2.6.21 |
| Jan Kundrát | kswapd high CPU usage with no swap |
git: | |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| David Miller | Re: [PATCH] tcp: splice as many packets as possible at once |
