Subject: Re: ARM cache and MMU
To: None <firstname.lastname@example.org>
From: Toru Nishimura <email@example.com>
Date: 01/18/2005 21:23:06
> Its ASID field
> eliminates the necessity to flush the entire TLB for every address space switch.
> It's as simple as write a new ASID value in TLBHi COP0 register.
The strength of ASID tag for TLB lookup and virtual address indexed physical
address tagged cache combination is made clearer in the case when two
procecess run in process model OS. Here, let's say we have two procs #0
and #1 in action.
TLB is a cache for VA->PA address translation. In essense it's nothing more
than virtually address tagged cache. Since ASID acts as a TLB lookup key,
a context switch for the proc#1 can be as simple as to write the new ASID
of proc#1. VA->PA translation keeps working to fetch new TLB entries for
proc#1 address space, leaving TLB entries for proc#0 purged as time goes.
Now, if proc#0 takes CPU again, survived TLB entries for proc#0 is found
alive. It's the case when cache does cache.
Virtual address indexed physical address tagged cache is equally versatile
for the case mentioned above. When proc#1 gains CPU control, cache lines
which holds proc#0 insn and data are considered defunct. Since the address
range arrangement of text , data and stack segments are common across
programs, invoking proc#1 is pretty likely to evict cache lines occupied by
proc#1. Now if cache is designed multi-way, say 2, cache line A and B hold
valid contents, for proc#0 and for proc#1. Then, proc#1 gets CPU control
again, the survived cache lines are found alive and useful to run proc#1 faster.
It is an acute constrast that virtual address tag belongs to each process address
space and full scale cache flush is hardy escaped for every context switch.
Toru Nishimura/ALKYL Technology