Section 9.4. Virtual Address Space Management

9.4. Virtual Address Space Management

A virtual address space is a container for a set of mappings. There is one address space for each process within the system, and one for the kernel. The address space layers manage setup and teardown changes to the address spaces on behalf of a process or the kernel, and MMU faults within.

9.4.1. Address Space Management

The Solaris kernel is implemented with a central address management subsystem that other parts of the kernel call into. The address space module is a wrapper around the segment drivers, so that subsystems need not know what segment driver is used for a memory range. The address space object shown in Figure 9.7 is linked from the process's address space and contains pointers to the segments that constitute the address space.

Figure 9.7. The Address Space

The address space subsystem manages the following functions:

Duplication of address spaces, for fork()
Destruction of address spaces, for exit()
Creation of new segments within an address space
Removal of segments from an address space
Setting and management of page protection for an address space
Page fault routing for an address space
Page locking and advice for an address space
Management of watchpoints for an address space

Recall that the process and kernel subsystems call into the address space subsystem to manage their address spaces. The address space subsystem consists of a series of functions, grouped to perform the functions listed above. Although the subsystem has a lot of entry points, the implementation is fairly simple because most of the functions simply look up which segment the operation needs to operate on and then route the request to the appropriate segment driver.

A call to the as_alloc() function creates an address space, but as_alloc() is invoked only oncewhen the system boots and the init process is created. After the init process is created, all address spaces are created by duplication of the init process's address space with fork(). The fork() system call in turn calls the as_dup() function to duplicate the address space of the current process as it creates a new process, and the entire address space configuration, including the stack and heap, is replicated at this point.

The behavior of vfork() at this point is somewhat different. Rather than calling as_dup() to replicate the address space, vfork() creates a new process by borrowing the parent's existing address space. The vfork function is useful if the fork is going to call exec() since it saves all the effort of duplicating the address space that would otherwise have been discarded once exec() is called. The parent process is suspended while the child is using its address space, until exec() is called. Once the process is created, the address space object is allocated and set up. The Solaris 10 data structure for the address space object is shown below.

struct as {         kmutex_t a_contents;    /* protect certain fields in the structure */         uchar_t  a_flags;       /* as attributes */         uchar_t a_vbits;        /* used for collecting statistics */         kcondvar_t a_cv;        /* used by as_rangelock */         struct  hat *a_hat;     /* hat structure */         struct  hrmstat *a_hrm; /* ref and mod bits */         caddr_t a_userlimit;    /* highest allowable address in this as */         struct seg *a_seglast;  /* last segment hit on the addr space */         krwlock_t a_lock;       /* protects segment related fields */         size_t  a_size;         /* size of address space */          struct seg *a_lastgap; /* last seg found by as_gap() w/ AS_HI (mmap) */         avl_tree_t a_segtree;   /* segments in this address space. (AVL tree) */         struct watched_page *a_wpage;   /* list of watched pages (procfs) */         int     a_nwpage;       /* number of watched pages */         uchar_t a_updatedir;    /* mappings changed, rebuild a_objectdir */         vnode_t **a_objectdir;  /* object directory (procfs) */         size_t  a_sizedir;      /* size of object directory */         struct as_callback *a_callbacks; /* callback list */ };                                                                             See vm/as.h

The following output from the DTrace vm.d script shows the path through the virtual memory layers as a process allocates more memory via brk():

0  => brk                                                13076 0    -> as_rangelock                                     13077 0    <- as_rangelock                                     13078 0    -> as_map                                           13082 0      -> seg_alloc                                      13087 0        -> seg_attach                                   13091 0          -> as_addseg                                  13093 0          <- as_addseg                                  13101 0        <- seg_attach                                   13102 0      <- seg_alloc                                      13104 0      -> segvn_create                                   13106 0        -> anon_resvmem                                 13108 0        <- anon_resvmem                                 13110 0        -> anon_grow                                    13117 0        <- anon_grow                                    13123 0        -> seg_free                                     13125 0          -> as_removeseg                               13127 0          <- as_removeseg                               13132 0        <- seg_free                                     13134 0      <- segvn_create                                   13137 0      -> as_setwatch                                    13139 0      <- as_setwatch                                    13141 0    <- as_map                                           13143 0    -> as_rangeunlock                                   13144 0    <- as_rangeunlock                                   13146 0  <= brk                                                13147

Address space fault handling is performed in the address space subsystem; some of the faults are handled by the common address space code, and others are redirected to the segment handlers. When a page fault occurs, the Solaris trap handlers call the as_fault() function, which looks to see what segment the page fault occurred in by calling the as_setat() function. If the fault does not lie in any of the address space's segments, then as_fault() sends a SIGSEGV signal to the process. If the fault does lie within one of the segments, then the segment's fault method is called and the segment handles the page fault.

Table 9.3 lists the segment functions in alphabetical order.

Table 9.3. Solaris 10 Address Space Functions
Method	Description
`as_add_callback()`	Register a callback for certain events from clients of the address space.
`as_addseg()`	Creates a new segment and links it into the address space.
`as_alloc()`	Creates a new address space object (only called from the kernel for the init process).
`as_clearwatch()`	Clears all watch points for the address space.
`as_ctl()`	Sends memory advice to an address range for the address space.
`as_delete_callback()`	Delete a callback.
`as_dup()`	Duplicates the entire address space.
`as_exec()`	Is a special code for `exec` to move the stack segment from its interim place in the old address space to the right place in the new address space.
`as_fault()`	Handles a page fault in the address space.
`as_findseg()`	Finds a segment containing the supplied virtual address.
`as_free()`	Destroys the address space object; called by `exit()`.
`as_gap()`	Finds a hole of at least the specified size within [base, base + len). If the flag supplied specifies `AH_HI`, the hole will have the highest possible address in the range. Otherwise, it will have the lowest possible address. If the flag supplied specifies `AH_CONTAIN`, the hole will contain the address addr. If an adequate hole is found, base and len are set to reflect the part of the hole that is within range, and 0 is returned. Otherwise, -1 is returned.
`as_getmemid()`	Calls the segment driver containing the supplied address to find a unique ID for this segment.
`as_getprot()`	Gets the current protection settings for the supplied address.
`as_incore()`	Determine whether data from the mappings in interval [addr, addr + size) are in the primary memory.
`as_map()`	Maps a file into the address space.
`as_memory()`	Returns the next range within [base, base + len) that is backed with "real memory."
`as_pagelock()`	Locks a page within an address space by calling the segment page lock function.
`as_pagereclaim()`	Retrieves a page from the free list for the address supplied.
`as_pageunlock()`	Unlocks a page within the address space.
`as_purge()`	Delete all segments in the address space marked with S_PURGE (for non-faulting segments).
`as_rangebroadcast()`	Wakes up all threads waiting on the address space condition variable.
`as_rangelock()`	Locks the pages for the supplied address range.
`as_rangeunlock()`	Unlocks the pages for the supplied address range.
`as_rangewait()`	Waits for virtual addresses to become available in the specified address space. `AS_CLAIMGAP` must be held by the caller and is reacquired before returning to the caller.
`as_setat()`	Finds a segment containing the supplied address.
`as_setpagesize()`	Set the page size advice for the range of supplied addresses.
`as_setprot()`	Sets the virtual mapping for the interval from [addr : addr + size) in address space `as` to have the specified protection.
`as_setwatch()`	Sets a watchpoint for the address. On a system without watchpoint support, does nothing.
`as_swapout()`	Swaps the pages associated with the address space to secondary storage, returning the number of bytes actually swapped.
`as_unmap()`	Unmaps a segment from the address space.

9.4.2. Address Space Callbacks

An address space callback is a facility which supports the ability to inform clients of specific events pertaining to address space management. An example of such an event is an address space unmap requestto prevent holding the address space's lock (a_lock) for a large amount of time during an unmap (which can cause ps(1) and other tools to hang), the unmap is performed as a callback without holding the a_lock. As one example, we use this facility to prevent an NFS server timeout from hanging ps.

A client calls as_add_callback() to register an address space callback for a range of pages, specifying the events that need to occur. When as_do_callbacks() is called and finds a matching entry, the callback is called once, and the callback function MUST call as_delete_callback() when all callback activities are complete. The thread calling as_do_callbacks() blocks until the as_delete_callback() is called. This allows for asynchronous events to subside before the as_do_callbacks() thread continues. An example of the need for this is a driver which has done long-term locking of memory. Address space management operations (events) such as as_free(), as_unmap(), and as_setprot() will block indefinitely until the pertinent memory is unlocked. The callback mechanism provides the way to inform the driver of the event so that the driver may do the necessary unlocking.

9.4.3. Virtual Memory Protection Modes

We break each process into segments so that we can treat each part of the address space differently. For example, the kernel maps the machine code portion of the executable binary into the process as read-only to prevent the process from modifying its machine code instructions. The virtual memory subsystem does this by taking advantage of the hardware MMU's virtual memory protection capabilities. Solaris relies on the MMU having the following protection modes:

Read. The mapping is allowed to be read from.
Write. The mapping is allowed to be written to.
Executable. The mapping is allowed to have machine codes executed within its address range.

The implementation of protection modes is done in the segment and HAT layers.

9.4.4. Page Faults in Address Spaces

The Solaris virtual memory system uses the hardware MMU's memory management capabilities. MMU-generated exceptions tell the operating system when a memory access cannot continue without the kernel's intervention, by interrupting the executing process with a trap and then invoking the appropriate piece of memory management code. Three major types of memory-related hardware exceptions can occur: major page faults, minor page faults, and protection faults.

A major page fault occurs when an attempt to access a virtual memory location that is mapped by a segment does not have a physical page of memory mapped to it and the page does not exist in physical memory. The page fault allows the virtual memory system to hide the management of physical memory allocation from the process. The virtual memory system traps accesses to memory that the process believes is accessible and arranges to have either a new page created for that address (in the case of the first access) or copies in the page from the swap device. Once the memory system places a real page behind the memory address, the process can continue normal execution. If a reference is made to a memory address that is not mapped by any segment, then a segmentation violation signal (SIGSEGV) is sent to the process. The signal is sent as a result of a hardware exception caught by the processor and translated to a signal by the address space layer.

A minor page fault occurs when an attempt is made to access a virtual memory location that resides within a segment and the page is in physical memory, but no current MMU translation is established to the physical page from the address space that caused the fault. For example, a process maps in the libc.so library and makes a reference to a page within it. A page fault occurs, but the physical page of memory is already present and the process simply needs to establish a mapping to the existing physical page. Minor faults are also referred to as attaches.

A page protection fault occurs when a program attempts to access a memory address in a manner that violates the preconfigured access protection for a memory segment. Protection modes can enable any of read, write, or execute access. For example, the text portion of a binary is mapped read-only, and if we attempt to write to any memory address within that segment, we will cause a memory protection fault. The memory protection fault is also initiated by the hardware MMU as a trap that is then handled by the segment page fault handling routine.

Figure 9.8 shows the relationship between a virtual address space, its segments, and the hardware MMU.

Figure 9.8. Virtual Address Space Page Fault Example

In the figure, we see what happens when a process accesses a memory location within its heap space that does not have physical memory mapped to it. This has most likely occurred because the page of physical memory has previously been stolen by the page scanner as a result of a memory shortage. In the numbered events in the figures we see:

A reference is made to a memory address that does not map to a physical page of memory. In this example, the page has been paged out and now resides on the swap device.
When the process accesses the address with no physical memory behind it, the MMU detects the invalid reference and causes a trap to occur on the processor executing the code of the running thread. The fault handler recognizes this as a memory page fault and establishes which segment the fault occurred in by comparing the address of the fault to the addresses mapped by each segment.
The address space as_fault() routine compares the address of the fault with the addresses mapped by each segment and then calls the page_fault routine of the segment driver for this segment (in this case, the vnode segment driver).
The segment driver allocates and maps the page of memory by calling into the HAT layer and then copies the contents of the page from the swap device.
The segment driver then reads the page in from the backing store by calling the getpage() function of the backing store's vnode.
The backing store for this segment is the swap device, so the swap device getpage() function is called to read in the page from the swap device.

Once this process is completed, the process can continue execution. The following example using the DTrace vm.d script shows the logical flow for a zero-fill on demand page fault.

0  -> as_fault                                            4210 0   | as_fault:as_fault                                   4210 0    -> as_segat                                          4211 0    <- as_segat                                          4212 0    -> segvn_fault                                       4213 0      -> anonmap_alloc                                   4216 0        -> anon_create                                   4219 0        <- anon_create                                   4224 0      <- anonmap_alloc                                   4225 0      -> anon_array_enter                                4227 0        -> page_get_pagecnt                              4228 0        <- page_get_pagecnt                              4229 0        -> anon_get_slot                                 4230 0        <- anon_get_slot                                 4231 0      <- anon_array_enter                                4232 0      -> anon_zero                                       4234 0        -> anon_alloc                                    4236 0        <- anon_alloc                                    4240 0        -> page_lookup                                   4243 0          -> page_lookup_create                          4244 0          <- page_lookup_create                          4245 0        <- page_lookup                                   4246 0        -> page_create_va                                4248 0          -> page_get_freelist                           4251 0            -> page_trylock                              4258 0            <- page_trylock                              4259 0            -> page_sub                                  4261 0            <- page_sub                                  4262 0          <- page_get_freelist                           4266 0          -> page_hashin                                 4268 0          <- page_hashin                                 4270 0          -> page_io_lock                                4272 0          <- page_io_lock                                4273 0          -> page_add                                    4275 0          <- page_add                                    4276 0        <- page_create_va                                4278 0        -> pvn_plist_init                                4279 0          -> page_sub                                    4280 0          <- page_sub                                    4281 0          -> page_io_unlock                              4283 0          <- page_io_unlock                              4285 0        <- pvn_plist_init                                4286 0        -> pagezero                                      4289 0        <- pagezero                                      4294 0        -> page_downgrade                                4296 0        <- page_downgrade                                4297 0       | anon_zero:zfod                                  4298 0        -> hat_page_setattr                              4299 0        <- hat_page_setattr                              4301 0      <- anon_zero                                       4302 0      -> anon_set_ptr                                    4303 0      <- anon_set_ptr                                    4305 0      -> hat_memload                                     4306 0      <- hat_memload                                     4316 0      -> page_unlock                                     4317 0      <- page_unlock                                     4318 0      -> anon_array_exit                                 4319 0      <- anon_array_exit                                 4320 0    <- segvn_fault                                       4321 0  <- as_fault                                            4322