The necessity of zeroing a page before assigning it to the working set of a
different process is a C2 security requirement. (For more information about NT's
C2 security rating, see "Windows NT Security, Part 1," May 1998.) The
operating system (OS) must reinitialize all OS resources (e.g., memory, disk
space, objects) before reassigning them to prevent the creation of security
holes in which one process can see another process' potentially sensitive data.
In some cases, the process does not require zero-filled memory, as when the
Memory Manager allocates a page to store data read from a memory-mapped file. In
these cases, the Memory Manager checks the free list for an available page
before it checks the zeroed list.
The final list is the bad page list. As its name implies, the bad page list
is an off-limits holding area in which the Memory Manager, with the support of
memory parity error detection, places pages it has detected as faulty.
The number of pages that are on the standby page, free page, and zeroed
page lists defines the free memory that various memory-tracking tools (e.g., the
Task Manager) report. The commit total is the amount of currently
allocated memory that paging file space backs. If the Memory Manager pages the
data in commit total memory out of physical memory, the Memory Manager stores
that data in a paging file. The commit limit is the amount of commit
total memory the Memory Manager can allocate without expanding the sizes of
existing paging files.
Shared Memory and Prototype PTEs
PFN Database entries contain varying information, depending on which state
corresponding pages are in. In most cases, a PFN Database entry contains a
pointer to a PTE that references a page. However, if two or more processes share
the same page, multiple PTEs reference the page: one PTE in the virtual address
map of each process sharing the page. Instead of pointing the PFN Database entry
at one of these PTEs, the Memory Manager points the PFN Database entry at a data
structure the Memory Manager allocates, called a Prototype PTE (PPTE), as
Figure 3 shows. I'll describe the way the Memory Manager uses PPTEs to manage shared and mapped memory.
I explained last month that to share memory, a process must create a
Section Object. Section Objects hold information about the name of a file, its size, and what portions of it are mapped. Section Object creation defines the shareable data, and each additional process that wants to participate in the sharing must map a portion of the data into its address space. This mapping is known as mapping a view of a section, because processes might map only a portion of the data that a Section Object defines.
When a process allocates a Section Object, the Memory Manager allocates
another data structure called a Segment. Segments contain storage to hold enough PPTEs to describe all the pages in the Section Object. Usually, when a page moves from a process' working set to the standby page, modified page, or modified no-write page lists, the Memory Manager marks the page's PTE invalid and sets a bit in the page to indicate that the page can be soft-page faulted, which means the PFN of the page stays in the PTE. PTEs that the Memory Manager marks as invalid for shared pages do not continue to store PFNs; rather, the Memory Manager updates them to point at the shared page's PPTE. This trick makes it easy for the Memory Manager to update the PFN of a shared page without
manually updating the PTEs that refer to the page in the address spaces of all
the processes that reference the page.
Consider an example in which two processes share a page. When the page's
data is in memory, each process has a valid PTE that stores the PFN where the
page's data resides in physical memory. If the Memory Manager removes the PTEs
from the working sets of both processes and sends the page's data to a paging
file, the PTEs are both invalid and contain pointers to the PPTE. When the
Memory Manager brings the page's data back into physical memory, the Memory
Manager updates the PPTE to reflect the page's new PFN. When one of the
processes tries to access the page, it generates a page fault. Then the Memory
Manager looks at the PTE, finds the new PFN in the PPTE the PTE points to, marks
the PTE as valid, and updates its PFN. When the second process accesses the
page, the Memory Manager updates that process' PTE similarly. Without this
optimization, the Memory Manager needs to track down both PTEs (or more, if a
greater number of processes shared the page) and update them when it brings the
page back into memory--an expensive and potentially wasteful operation.
A reference count in the PFN Database tracks the number of processes that
access a shared page, and the Memory Manager knows that when the count becomes
zero, the page is not marked valid in any working set. At that point, the Memory
Manager moves the page to the standby page or modified page lists.
Memory-Mapped Files
Memory-mapped files are a special form of shared memory. When a process maps a file into its address space, the Memory Manager creates several support data structures that aid the process' interaction with file systems. Figure 4 shows how these data structures are related. A File Object represents the file on disk, and the File Object is the target of all I/O the Memory Manager performs on the file. The Section Object points at its Segment, which contains the PPTEs for the Section Object. The Segment points to a control area that the File Object also points at. This control area is the nerve center for a mapped file, so that even if a process creates more than one Section Object for a file, there is still only one shared con-trol area.
When a process references a virtual address that the process indicates
should be backed by a file, the Memory Manager examines the Virtual Address
Descriptor (VAD) that describes the memory range, then locates the control area.
The Memory Manager allocates a page of physical memory to bring the requested
data into and updates the PTE for the virtual address map. Because the Memory
Manager finds the File Object through the control area, the Memory Manager can
initiate an I/O operation to the file system that owns the disk on which the
file resides. The operation reads the page from the file on disk (the page is in
the transition state while the I/O is in progress). After the operation reads
the page, the Memory Manager marks the PTE as valid and lets the process
continue its attempt to access the data, which is now present.
A caveat with regard to memory-mapped files exists: Files can map as data
files or as images. Files map as images when the NT Process Manager loads them
for execution. The same file can map as a data file and an image, and
maintaining separate control areas for data files and images lets NT ensure the consistency of the different mappings that different processes make.
More on Memory
Last month, I claimed that memory management is one of the most complex
tasks an OS faces. In this two-part series on memory management, I've provided only an overview of the policies and mechanisms NT implements to provide applications with memory resources appropriate to their needs and the needs of other concurrently running programs. If you want to learn more about the Memory Manager, I recommend Inside Windows NT, Second Edition, by David A. Solomon (Microsoft Press).
Next month, I'll cover a subsystem that's closely tied to the Memory
Manager--the Cache Manager. I'll discuss how the Memory Manager sizes system
working sets (including the file system cache) differently from process working sets.
End of Article
Prev. page
1
2
[3]
next page -->
