The third case is where the faulting page is
not available in the cluster memories at all. In
other words, the only copy exists on the disk.
So in this case, what has to happen is, when
we have the page fault on node P for this x, we have to go to the disk to
fetch it. And we're going to fetch it, which
means that the working set on node P is growing,
similar to the first case. And so the local part is
going to go up by one. In order to make room for
that, I have to necessarily shrink the global part as in
the first case. So, I am going to shrink that global part by
1. By the way, I can pick any page from the
global part, and both in the first case, as well as in
this case, we can pick any page from the global part and
send it out to a peer memory. And that's what we're doing
here, so we are saying, here is a page that I have to get rid of. Who do I send
it to? Well, I am going to send it to the
guy that happens to have the globally oldest page in the
entire cluster. So let's say there is some host R
that has the globally oldest page in the entire cluster, and
that globally oldest page in the host R could be
on the local part or the global part of this host.
So what we're going to do is, we're going to tell that
guy, hey, I'm going to give you a page to hold,
because this used to be in my global part, I
don't have room anymore, because my local is increasing by one
because of this page fault, and adding x to my
working set now. So please hold on to this page that
I'm going to give you, in your global cache. Now
this guy has a split like this. So if it has
to make room for this new page that is
coming in from its peer, clearly it has to get
rid of something. Where it will get rid of? Well,
it has to throw it on the disk. Now, the
interesting part is, if the oldest page on host R happens
to be in the global cache of R, what can we say about that page z?
Well, it has to be cleaned, because global part is nothing but a
paging device. And therefore if it is here, it must
be cleaned, and therefore, I can discard it without worrying
about it. Just simply dump it. Drop it on the
floor [LAUGH]. That's what I'm going to do. On the other
hand, if it is on the local part, it could
be dirty. That is, if the oldest page happens to
be on host R, and it also happens to be
in the local part of host R, it is conceivable
that this page has been modified, in which case,
that modified copy has to be written out to
the disk. So in other words, when we pick
host R to send this replacement page from my host,
this guy, what he's going to do is, he's going to say, I have to get rid of
a page in order to make room for this
incoming global page, because i have the globally oldest page.
And if I have the globally oldest page, then let
me get rid of it by throwing it out onto the
disk if it happens to be dirty. If it happens to
be clean, simply drop it on the floor, because I know
that all the pages are contained on the disk. That's the
fundamental assumption we started with, that all the pages of the
currently active processes are on the disk. It is just that
the global cache of every node is acting as a surrogate
for the disk, because it can be faster to
access from the peer memory than from the disk. So
similar to the first case, in this case also,
the local portion of the physical memory allocation on host
P is going to go up by one, and the
global portion is going to go down by one. What
about host R, well it really depends. If the oldest
page on host R happens to be in the global
cache, then there is no change, because I am
reading the old page z for another page that is
coming in from host P, that is y that
is coming in. In that case there is no change
in the allocation between local and global on host
R. But on the other hand, if the globally oldest
page happens to be from the local part of
host R, what that means is that even though originally
we thought z to be part of the working set of host R, clearly, the processes
that were using it are either no longer
active, or they're completed, or whatever, and therefore,
we're throwing out this page. The local part
is shrinking. If the local part on host
R is shrinking, what that means is, I
can use more of the memory that's available
in host R for community service. That's the
important message I should get out. That's the
important message I want you to get out
of looking at this particular page fault scenario.