Jakko Pastuchio wrote:
On 9/13/06, Amol Lad <amol@xxxxxxxxxxxxxxxxxxx> wrote:On Wed, 2006-09-13 at 12:58 +0200, Jakko Pastuchio wrote: > I've noticed that the flush_icache_* routines on the i386 > are nothing more than an empty do{}while(0) stub. > does anyone know why is that ? If my understanding is correct then these functions are mainly required for virtual caches where you need to flush instruction cache say during context switch. It's not required for x86 as x86 caches are physically tagged cacheshmm. thanks for that insight. but what about events when the *physical* address space has changed (e.g. module loading) ? we still need to invalidate the cache, don't we ? so is there a way to invalidate instruction caches on the x86 ?
For the case of module loading (or, say, setting a breakpoint) explicit cache flush and/or invalidate insn are needed iff: a) there are separate insns and data caches, and b) the insns and data caches are not kept coherent. Then the proper sequence is: a) flush the data cache (so modified insns go to memory) and, b) invalidate the insn cache, so the up-to-date insns are fetched from memory. On P6 and P5 processors, a write to a cached code segment automagically invalidates the appropriate cache line in the insn cache. For Pentium 4 and Xeon, the role of an insn cache preforms the "trace cache" - a cache, which stores decoded micro-ops. On Pentium 4 and Xeon, a write to a code segment invalidates *the entire trace cache*. Thus, after such a write, the insns are again fetched and decoded from the L2 cache, thus no need for an explicit invalidation. There's no need to flush the data cache either, because the L1 data cache is write-through and the L2 cache is unified. ~velco -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
