0
votes

I know a cache is not flushed at context switch. So if the new process has demanded a page that maps to the same physical address as the previous process (and the prev process is now swapped to disk), the contents of the previous process would still be cached. Wouldn't they be accessed by the new process when it tries to access its part of the memory from the physically mapped cache?

1

1 Answers

4
votes

if the new process has its virtual memory mapped to same physical address as the previous one.

For most contemporary Operating systems, Answer to your question is Paging.

Let say you have an OS with 4GB of addressable memory but the physical memory installed on the system is only 2GB. Further assume that one process with 1.5GB of memory requirement is active, so it looks as something as following.

enter image description here

Because there is enough physical memory, complete virtual address space of this process is mapped to physical memory.

Now lets say a new process with 1.5GB memory requirement enters the system. since there is not enough physical memory for both the processes, address space of first process may be mapped to disk(paged out), given that second process actively needs entire 1.5GB of its space. So now the situation looks as follows.

enter image description here

Please note that from the perspective of first process everything is as before, as soon as it becomes active and uses its virtual space, The OS will page back in its memory space stored on disk to the physical memory.

I know a cache is not flushed at context switch. So if the new process has demanded a page that maps to the same physical address as the previous process (and the prev process is now swapped to disk), the contents of the previous process would still be cached of memory protection.

Your premise is not entirely correct, where did you read that cache will not be flushed?

The question of invalidating caches on context switch is dependent on factors, some of which are not under control of an OS.

Some OS implementation do flush the caches (read below) and the ones that dont do it, require special support from the hardware. Either way any OS worth its salt will make sure that invalid data is not served to any process.

Following is relevant text from some very good OS books.

From Understanding the Linux Kernel

Table 2-11. Architecture-independent TLB-invalidating methods

Method name -- flush_tlb
Description -- Flushes all TLB entries of the non-global pages owned by the current process Typically used when -- Performing a process switch

If the CPU switches to another process that is using the same set of page tables as the kernel thread that is being replaced, the kernel invokes _ _flush_tlb() to invalidate all non-global TLB entries of the CPU.

From Modern Operating Systems

The presence of caching and the MMU can have a major impact on performance. In a multiprogramming system, when switching from one program to another, sometimes called a context switch, it may be necessary to flush all modified blocks from the cache and change the mapping registers in the MMU.

and From the Operating System - three easy pieces

One approach is to simply flush the TLB on context switches, thus emptying it before running the next process. On a software-based system, this can be accomplished with an explicit (and privileged) hardware instruction; with a hardware-managed TLB, the flush could be enacted when the page-table base register is changed (note the OS must change the PTBR on a context switch anyhow). In either case, the flush operation simply sets all valid bits to 0, essentially clearing the contents of the TLB. By flushing the TLB on each context switch, we now have a working solution, as a process will never accidentally encounter the wrong translations in the TLB.

On the other hand To reduce this overhead, some systems add hardware support to enable sharing of the TLB across context switches. In particular, some hardware systems provide an address space identifier (ASID) field in the TLB. You can think of the ASID as a process identifier (PID), but usually it has fewer bits (e.g., 8 bits for the ASID versus 32 bits for a PID). If we take our example TLB from above and add ASIDs, it is clear processes can readily share the TLB: only the ASID field is needed to differentiate otherwise identical translations.