Re: Flushing instruction cache

Martin wrote:

One other thing bothers me, unfortunately.

In the documentation is says: Flushes internal cache, then signals the
external cache to write back current data followed by a signal to flush
the external cache.

So in other words, after the execution of the WBINV the L1 cache will be
invalidated before the next instruction will be executed. Moreover, in
the documentation it also says that this instruction takes 5 cycles.
However, when I did some performance measurements with the TSC than
it calling the WBINV instruction makes a difference of 2 Mio (!!!) clock
cycles. It cant take that long to invalidate internal 32KB caches, can it?

Yes, this were the expected timing penalty ...
WBINV takes at least (min latency) ~2000 cycles plus the time needed
to write-back all dirty pending cache lines.

you can use INVD (invalidate without write back), but then you should
be aware of what you may loose ...

write-through may be a solution if you can stand some penalties on WR.

I'd also look at the new various flash-instructions beside the few
cache-bypassing WR-opportunities (NTMOV..)

and there are the so-called serialising things like CPUID, which
may be of help for more exact time measurements by RDTSC.