next up previous contents index
Next: 15.2.1 Region flags Up: 15 List-based Memory Manager: Previous: 15.1 Introduction

15.2 Memory regions

 

The LMM maintains a concept of a memory region, represented by the data type lmm_region_t, which represents a range of memory addresses within which free memory blocks may be located. Multiple memory regions can be attached to a single LMM pool, with different attributes attached to each region.

The attributes attached to memory regions include a set of caller-defined flags, which typically represent fundamental properties of the memory described by the region (i.e., the ways in which the region can be used), and a caller-specified allocation priority, which allows the caller to specify that some regions are to be preferred over others for satisfying allocation requests.

It is not necessary for all the memory addresses covered by a region to actually refer to valid memory locations; the LMM will only ever attempt to access subsections of a region that are explicitly added to the free memory pool using lmm_add_free. Thus, for example, it is perfectly acceptable to create a single region covering all virtual addresses from 0 to (oskit_addr_t)-1, as long as only the memory areas that are actually valid and usable are added to the free pool with lmm_add_free.

The LMM assumes that if more than one region is attached to an LMM pool, the address ranges of those regions do not overlap each other. Furthermore, the end address of each region must be larger than the start address, using unsigned arithmetic: a region must not ``wrap around'' the top of the address space to the bottom. These restrictions are not generally an issue, but can be of importance in some situations such as when running on the x86 with funny segment layouts.





University of Utah Flux Research Group