[Autogenerated] let's examine how the member manager manages
physical pages in order to make things work as smoothly as possible
without incurring too many hard page faults.
So it manages all these pages in a bunch of lists.
The first list is called the bed page list.
These are physical pages that have been identified as
defective from a hardware perspective.
So obviously they cannot be used,
I will say in parenthesis that they're also used by memory enclaves
and discuss what that means a little bit more in the last module in
the course then we have processes.
Every process has a bunch of working set pages or pages which
are part of the working set that accessing them right now
would not cause any page fault.
And that's just a subset of the entire set of committed memory in the process.
But now we're only focusing on the physical pages,
not about the entire committed pages in the process.
There's another list known as a free page list.
The free page list consists of pages in physical memory,
of course that have some garbage value that belong wants to various processes,
but now these are up for grabs.
So essentially they are free to be used whenever memories needed.
That's one option from where to grab physical pages
for processes that need them.
Then there's another list called the zero page list.
Zero page list is also a list of pages that don't belong to anyone,
but the list of pages here contain the very famous number zero.
So these pages are completely zeroed out.
You might be wondering why do we need that?
So we'll see in a moment, this is in fact an optimization.
What happens that you have have a threat.
In fact,
there are several threads in modern windows that are called zero page
threats and these threats have priority of zero,
which means that's the lowest possible priority,
Windows support, which means that if the CPU does nothing,
there's at least one process or doing nothing.
The zero page thread might run.
And what that threat does is takes pages from the free page list which
contains some kind of garbage and then zeros them out and grabbing them
and moving them to the zero page list,
essentially making dirty pages completely zeroed out.
In fact, typically what you'll find is that the three page list is very,
very small and the zero page list is very big in terms of
pages that are up for grabs and that's because there's no
downside to having a page with zeros.
But there is one important upside, we'll see in a moment.
So in the process, for example exits.
So a process terminates.
For whatever reason,
all the private physical memory it was using is going to go to the
free page list because some garbage is there,
it's going to go to the free page list and then the zero page thread will
likely wake up very quickly and will zero out all these pages,
putting them on the zero page list and we'll see that in the next demo.
What else could happen here?
This is the case of demand zero page for that.
I mentioned a few videos back.
The basic idea is this when we call a function such as mutual Alak and
we've seen an example of that earlier in the course,
we always get a bunch of zeros.
This is guaranteed the reason for that has to do with security.
And so it's not allowed for a process to get some garbage data
that might have belonged to a different process.
Even if that process is no longer alive.
And so demand zero page faults.
Mean that when a process commits memory,
like calling mutual dialogue, it doesn't mean it means that memory right now,
but when it makes the access that causes a page fault of demand zero type.
And the memory manager is happy to oblige by providing zero
page or pages to the processing question.
So it's important to have the zero pages ready as optimization.
So you might be thinking, well maybe the system would be very,
very busy, lots of threats running all the time.
All the process was really busy and maybe because of that,
the zero page threat doesn't get enough CPU time to run and
maybe the zero page list is completely depleted.
Could that happen?
In theory?
Yes, it could happen.
And in that case you want to get some garbage page because
that would be against the rules instead.
At that point in time when that demand zero page fault should happen,
the mail manager will grab a free page,
zero it out at that point in time and then hand it
over to the processing questions.
So there are no circumvention of rules here.
However,
the zero page list is definitely a nice optimization because these pages are
already ready with zeros and there's really no benefit to the free page list
and that's why that list is typically very,
very small.
What else?
Another thing that could happen is that the three page list could
be used for kernel allocations for instance,
because when kernel code allocates memory,
it's considered okay to see memory that might have
belonged to some process or another.
Even if that process is alive or not,
doesn't really matter because if you are a kernel component or a kernel driver,
you can look at any process memory anyway and you're not really restricted.
So having that kind of thing giving you always zero page
doesn't really bring that much benefit.
So that's considered okay for kernel allocations to see garbage that
may have belonged to a process one or another.
Also this might happen when you have to read things from disks.
So if for example,
you load the DLL the committing of the memory there and
then you have to read the data to memory.
So essentially the colonel can grab a free page list,
sorry,
free page or some free pages as needed based on the size of the DLL
and then load the data directly to those pages.
And that's okay because the user mode code can't see what
was there before the DLL was loaded.
The code and data is actually just overwriting whatever garbage was there.
That's also considered okay to try to minimize,
to some extent the usage of the zero pages,
which has a very slow specific role in this story.
So what else,
what happens when process uses too much ran or the working set
becomes too great and perhaps the colonel decides maybe it's
time to take some of these pages out.
So instead of just throwing them away to the free page list,
which would be definitely the simplest thing to do.
Um the colonel uses a slightly more complex scheme to
try to minimize hard page faults.
And this is based on some other lists that I'm going to describe Now,
the first one is the standby page list.
The standard page list represents pages that belong to
processes that have not been changed since the last time
they were written to the page file,
which means that if the process doesn't use a page,
for example, for a while, instead of just throwing that to the free page list,
it's going to move to the standby page lee saying,
well, you kind of one ft out the door but not out the door yet.
So the connection to the original process is still maintained.
So if now the process suddenly decides to use that memory,
a soft page fold would occur and that page will be brought back
to the working set of the process in question.
So that minimizes hard page faults significantly as we see in the next demo,
if the standby page list becomes too big or the free page list
and the zero page list become too small,
then some pages from the standby pages will have to
trickle to the free page list,
essentially losing their connection to the original process.
So now they're up for grabs.
So in some cases that might be necessary,
the system is starting to be very low on physical memory.
There is another similar list called the modified page list.
A modified page list also contains pages which haven't been accessed
recently by processes but their content has not yet been synchronized with
the page file so they can't be thrown away just yet.
So what we have here is that if a process not using some kind
of page in its working set for a while,
that might go into the standby page list or the modified page
list based on whether that has changed since it was last
written to the page file or not.
If it has, it will go to the modified page list and then again,
if the process suddenly decides to use that page,
it can be faulted back very quickly to the process working set.
This is another kind of soft page faults, which is very quick.
It doesn't require any kind of io because the connection
to the process is still maintained.
However, if the modified pages becomes too big,
there's a thread called the modified page writer.
Its purpose is to wake up and then synchronize or
right modified pages to the page file.
And so now these pages can go to the standby page list.
So at that point they can either return to the process.
Working with the process decides to use them or if the free
page list and zero page list become too small,
these standby pages can now trickle to the free page list,
losing their connection to the original process.
So these page dynamics,
you got to get a sense here that the colonel is doing its
best to minimize hard page faults by using the standby page
list and the modified page list.
And optimize giving processes memory by having the
zero page list there being managed