Re: Cache flushing...

Tim Olson (
Sun, 2 Jul 1995 14:15:13 -0500 (CDT)

| If the free pages have no icache in them, we can safely do a
| fork/exec/whetever, as any new pages given to a process will be
| guaranteed to not have stale icache data. Note that it's not the
| fork/exec system calls per se that are problematic for icache: any
| operation that maps in pages into user space would otherwise have to
| make sure that any new pages loaded aren't "tainted" by icache.

Correct. I mentioned fork/exec because my MINIX port to PowerPC
handles it there (as MINIX is segment-based, rather than page-based).
The I/D cache coherency must be managed anytime a physical page is
modified and might contain instructions.

| So, easy way to handle icache invalidation:
| - when a process is unmapped (free_page_tables() or
| clear_page_tables()), invalidate the whole icache for that process.
| - when any page is free'd from a process address space, invalidate the
| icache for that page (this happens either when a memory map is
| closed down or when a page is swapped out).
| The reason we do it this way is that neither the process unmap or the
| page unmap operation is very timing critical (the former happens just
| once in the lifetime of a program, and the latter happens mainly when
| you're low on memory and you need to swap, in whcih case other things
| will make the machine slow anyway). So if flushing the icache is a
| costly operation (on the alpha, for example, it's an all-or-nothing
| operation), this is the better approach (instead of flushing the icache
| every time you map in a new page).

This takes care of one half of the coherency (invalidating the
icache). What about the other half: ensuring the data (instructions)
are valid in memory (rather than just in the data cache) when an
instruction fetch occurs?

Since you have to do this every time the processor modifies a physical
page that may contain instructions, why not perform the icache
invalidation there, too?

Tim Olson
Apple Computer / Somerset