The next myth is regarding memory effects. And that myth concerns the assertion
that the lost of locality in a micro-kernel base design, is much more than in a
monolithic structure. Or the structure that is
advocated in spin and exo-kernel. But before we
talk about the memory effects. There's a
primer on the memory hierarchy. You know that,
in the process of architecture, you have the
CPU, you have the TLB. And you have several
levels of caches, main memory. And the virtual memory
that resides on the disk. And these caches are
typically physically tagged. Now, what do we mean by
memory effects? What we mean by that is, if
you have this hardware address space, and this of
course is much bigger than the amount of space
that's available in these caches. And in
fact, we know that the entire hardware address
space may not even be in physical
memory. Because In a demand-based system, when a
process is executing, the pages that it
needs will be demand paged from the virtual
memory that's on the disk, and brought
into physical memory. And when the processor is
executing instructions, then the instructions and data
contained in physical memory move into the memory
hierarchy close to. The CPU, so that the CPU can access the working set of
the currently running thread by getting it from the cache that is closest to it.
That's the hope in this memory hierarchy. What
we mean by memory effects is when we
context switch between protection domains, how warm
are the caches? Now recall that if
we have small protection domains. P1, P2, P3, P4. Let's say they are all small
protection domains. In that case, led case
suggestion is, don't put each of these in
its own hardware address space. Pack them
together in the same hardware address space and
then force protection, for these processes from
one another, through segment registers. So when we
have small protection domains, then, the caches
are going to be pretty warm. Even when you
do a context switch from one process
to another process. There's a good chance, that
the cache hierarchy is going to contain the working
set of the newly scheduled small protection domain.
So in other words, the memory effects can be mitigated by carefully structuring
the protection domains, in the hardware
address space. So debunking the second myth
with respect to address space switching, also helps in reducing the ill effects
of implicit costs, associated with address
space switching, because these small protection domains.
Occupy only a small memory footprint, and
therefore occupy only a small memory footprint in
the caches as well. And therefore, when we
go across small protection domains, there's a good
chance that, the locality for the newly
scheduled small protection domain is going to be contained
in the cache hierarchy. So the caches are probably going to be warm, when we do
context switches, so long as the protection domains are small. We already
mentioned that if the protection domains
are large, you cannot avoid that. Whether
it is a monolithic kernel or. The exokernel, or the spin type
of extensibility. If the memory footprint of the system service is so big,
it is going to pollute the cache when
we visit that particular system service. So
even if we have a monolithic kernel,
and the monolithic kernel has subsystems, that occupy
a significant portion of the hardware address
space. Even though we are not doing any
context for it, the ill effects of
implicit costs in the memory hierarchy is going to
be felt. Because the cache is after
all a physically tagged. And therefore, when we
go from large protection domains, or large subsystems
in the context of a monolithic kernel. You
have to incur the cache pollution. So that
ill effect is unavoidable for large protection domains.
So the only place where a monolithic kernel can win, or an exokernel can win, or
a spin can win, is in small protection domains. And a microkernel can also
win for a small protection domain, by
packing multiple small protection domains in the
same hardware address space. So this begs the question. Why was it so bad in
Mac? Recall, I mentioned that, in Mac, on the same hardware, border crossing
cost 800 more cycles, compared to the border crossing in the L3 microkernel.
So we can ask the question, why was it so bad in the Mac microkernel?