The second myth concerns going across protection domains and espeiclaly if the
protection domains are impmlemented as distinct
hardware address spaces, then the myth
is that crossing protection domains implemented
using hardware address space switch is
expensive. And we are now talking
explicit cost for crossing protection domains implemented
as distinct hardware address spaces. Not the implicit
cost, we're only talking about the explicit cost
of crossing protection domain. Now, let's understand what
is involved in an address space switch. This
is a refresher to show you what exactly
is happening in terms of translating a virtual
address to a physical address. You all know
about the concept of a TLB and the virtual
address consists of two parts; an index part and a tag. The index is used to
look up the TLB and the tag that is contained in that particular entry of the
TLB is matched against the tag coming from
the virtual address. If they match, then we
got a hit, then this particular virtual address
is contained in the TLB entry and you've got
the physical frame number that corresponds to the
virtual page number that you started with, so
that is your, very simple, TLB, matching hardware
that does the address translation from VPN to
PFN. Now what happens on an address space
switch? That is a context switch going from
one address space to another address space. On
a context switch, the virtual address to physical address
mapping will change for the new process that
is going to be scheduled. So in other words,
if this TLB contains the translations for a
particular process that is currently executing on the
CPU, if we do a context switch, do we have to flush the TLB because the
virtual address to physical address mapping is going to
be different for the new process or new thread
that is going to run on the processor now? The answer to the question do
we have to throw away the mappings that exist in the TLB, when we do a context
switch, is, it depends. It depends on whether the
TLB has a way of recognizing that the
virtual to physical address translation that is contained in it, is flagged
by the distinct process for which those translations have been put into
the TLB. In other words, if the TLB has address
space tags in addition to the tag for disambiguating one
virtual address from another virtual address then you don't have
to flush the TLB. So these are what are called address space tag TLBs
which contain the process ID for which a particular TLB entry is present
in the TLB. MIPS Architecture for instance uses address space tagged TLBs.
But on the other hand, an architecture may not use an address space tagged TLB.
Intel 486, and Intel Pentium are examples of architectures that
do not have address space tags associated in
the TLB. So, in an Intel architecture, at
the point of the context switch, you have
to throw away all the entries that are there
in the TLB on behalf of the process.
In the Intel architecture, actually the TLB is
split into two parts, a user part and
a kernel part. And the kernel part is common
regardless of which process is running. And
therefore, you don't have to flush that portion
of the TLB, the kernel portion of the TLB, but the user portion of the TLB
has to be flushed on a context
switch because the virtual address, the physical address
mapping, is going to be different for the new
process that starts to run on the processor.