4
$\begingroup$

This question already has an answer here:

Suppose the L1 cache is filled up with data from some process. Now CPU loads another process. Does the new process share cache contents? Or the cache has to be invalidated completely in each context switch?

$\endgroup$

marked as duplicate by Paul A. Clayton, Rick Decker, David Richerby, Nicholas Mancuso, Luke Mathieson May 5 '15 at 6:12

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

6
$\begingroup$

It depends, there are several kinds of caches.

Some caches, known as PIPT (physically indexed, physically tagged) operate entirely on the physical address. The cache subsystem is independent of virtual memory, so it doesn't matter which process is accessing the cache: all processes share all cache entries.

Some caches, known as VIVT (virtually indexed, virtually tagged) operate entirely on the virtual address. In this system, a cache entry is only valid for a given process. There are several ways to ensure that a cache entry will not be used in the wrong process:

  • The operating system may flush the cache at each context switch. This requires no hardware support but is obviously inefficient unless context switches are rare.
  • The operating system may assign disjoint sets of addresses to distinct processes. This again requires no hardware support, but is a heavy burden on the operating system (it means that the MMU is effectively as a mere MPU (memory protection unit)).
  • The MMU and cache may contain an extra label which is set by the operating system to an identifier for the process that owns each page or cache entry. ARM and Intel call this label ASID (address space ID). Each cache entry is only valid for a virtual address with the matching label.
  • There are also VIPT caches (virtually indexed, physically tagged). The physical tagging ensures that the cache entry will only be served to a request for the correct chunk of memory. The virtual index means that if a page is shared at different addresses in different processes, the cache entries will not be shared.

See the “Address translation” section in the Wikipedia article for more information on these kinds of caches.

Cache types typically vary between processor families within the same processor architecture. Even on a given processor, data and instructions caches may have different types, as can L1 vs L2 (and more) caches.

$\endgroup$
  • 1
    $\begingroup$ +1 For flushing "no hardware support" may be a slight exaggeration. Unless the OS "flushes" the cache by loading shared—at the same virtual address—or inaccessible content, the hardware would have to support some kind of flush instruction. (Even this kind of "flushing" would require OS knowledge of size, indexing function, associativity, and replacement policy.) A flush instruction for a specific address or page may be useful for other reasons (though still may not be necessary for a working system), but flush index or flush cache is less broadly useful. $\endgroup$ – Paul A. Clayton May 27 '14 at 12:39
  • $\begingroup$ If hardware recognizes context switches (e.g., a write to a special register with the page table base), it can transparently implement ASIDs. A 1-bit hardware-managed ASID would allow gradual flushing of the cache in the common case of a context fully using the cache. Other than having content that is shared across contexts generating false misses (and delay in continued flushing if a new context does not fully use the cache), this can be indistinguishable from PIPT. (With OS-based ASIDs flushing is needed for ASID reuse.) Write-through and instruction caches can be invalidated in 1 cycle. $\endgroup$ – Paul A. Clayton May 27 '14 at 12:55
  • $\begingroup$ I realize these comments are beyond the level of the original question and are a bit chatty, but I wanted to share the thoughts. $\endgroup$ – Paul A. Clayton May 27 '14 at 12:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.