The present disclosure relates generally to storage in a segmented memory architecture. In particular, the present disclosure relates to creation and management of memory pools in a segmented memory architecture.
In computing systems, memory management is responsible for coordinating and controlling use of memory. For example, memory management techniques are utilized for selecting a particular memory area for allocation (e.g., for storage of internal file information blocks, task attribute blocks and user created programmatic data structures of a particular type or size) or reclamation (e.g., in the case of deleted system data structures or otherwise deallocated memory space). A major issue in memory management, and storage allocation in general, is the efficient selection allocation of memory for storage of data structures of different types and sizes.
Computing systems have evolved to adopt either paged or segmented memory architectures. In a paged memory architecture, each process uses virtual addresses in a virtual address space, which is managed through pages in memory by the operating system software and memory management unit hardware. In a segmented memory architecture, each process addresses variable length memory data segments using indirect references (e.g., descriptors) to manage available physical addresses in a monolithic address space.
A major issue in both types of memory addressing architectures, a central problem is the management of memory fragmentation. Memory fragmentation relates to the inability to use available memory due to the arrangement of memory already in use. For example, memory fragmentation can relate to a state where unallocated, free space is “checker-boarded” throughout memory rather than in large contiguous chunks of available memory. Therefore, instances can arise in which sufficient memory space should be available, but an allocation request cannot be accommodated due to the fact that no contiguous memory area is available.
Memory fragmentation occurs in a number of ways. In one example, referred to as “external” fragmentation, a large number of small areas are available for allocation, but none of these areas are large enough to satisfy a current memory request. In a further example, referred to as “internal” fragmentation, additional memory is allocated than is actually requested, for example due to padding requirements, header requirements, cache alignment requirements, or other requirements.
To address the issue of memory fragmentation, memory management systems include algorithms for selecting memory for allocation carefully. For example, memory allocation algorithms attempt to allocate memory based on finding a best fit free space for the request. As the size and complexity of memory and computing systems increases, fragmentation issues increase exponentially. Memory management algorithms coincidentally increase in complexity and require additional overhead, causing increasing time delays in memory allocation.
As an additional drawback, during a memory allocation, a “lock” is placed on the entire memory space to prevent multiple allocations of the same memory space by different resources. This is particularly important in multiprocessor systems that access a common, contiguous, shared memory space. When one processor attempts to allocate memory, others are prevented from allocating memory due to this global memory lock, causing delay in an entire computing system, and preventing parallel processing.
For these and other reasons, improvements are desirable.
In accordance with the following disclosure, the above and other issues are addressed by the following:
In a first aspect, a computing system is disclosed that implements a memory management scheme. The computing system includes a plurality of memory pools formed in a segment-addressable memory, each of the memory pools including one or more pool areas having a common size and a size class, wherein the size class defines a maximum amount of memory able to be allocated from the memory pool. The computing system also includes a memory pool management system interfaced to the segment-addressable memory, the memory pool management system including one or more memory pool tracking lists configured to track usage of the plurality of memory pools.
In a second aspect, a method of managing memory in a computing system having a segment addressable memory is disclosed. The method includes allocating memory in a computing system. Allocating memory includes identifying a memory pool in which memory is to be allocated, the memory pool including at least one memory pool area and selected from among a plurality of memory pools having a common size and a size class, wherein the size class defines a maximum amount of memory able to be allocated from the memory pool. It also includes locking the memory pool, locating a memory pool area within the memory pool having an available entry, updating an availability of the memory pool, updating a status of the memory pool area, and unlocking the memory pool area.
In a third aspect, a computing system implementing a memory management scheme is disclosed. The computing system includes a plurality of memory pools formed in a segment-addressable memory, each of the memory pools including one or more memory pool areas including pool area control data and a plurality of pool objects, each of the memory pool areas having a common size and a size class, wherein the size class defines a size of each of the plurality of pool objects in that memory pool area. The computing system also includes a memory pool management system interfaced to the segment-addressable memory. The memory pool management system includes a plurality of memory pool tracking lists including a full area list, a partial area list, and an empty area list. The memory pool tracking lists are configured to track usage of the plurality of memory pools. The memory pool management system is also configured to, in response to a memory allocation request, select a memory pool, memory pool area, and pool object from which memory can be allocated.
Various embodiments of the present invention will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the invention, which is limited only by the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the claimed invention.
The logical operations of the various embodiments of the disclosure described herein are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a computer, and/or (2) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a directory system, database, or compiler.
In general the present disclosure relates to creation and management of memory pools in a segmented memory architecture. Generally, memory pools refer to grouped, commonly managed memory areas used for storage and management of relatively small sized requests for memory. During operation of a computing system implementing memory pools according to certain embodiments disclosed herein, relatively small-sized objects can be placed into pools to be treated as a larger memory structure by an existing segment-based memory management system. Such a pooled arrangement allows for improved management of memory fragmentation, at least in part by supporting compaction of like-sized memory objects into a common memory pool.
In the various embodiments described herein, each memory pool is associated with a number of memory pool areas that can be allocated for data requests of a constant size for that memory pool. Memory pool areas correspond to individual blocks of memory to be used in a memory pool. In certain embodiments, the memory pool areas are all commonly sized, regardless of the memory pool to which the memory pool area belongs. This allows simple exchange of storage locations of the memory pool areas between memory and back storage, and dynamic reallocation for different sized data objects.
The memory structures disclosed in the memory pooling arrangement of the present disclosure can be allocated, deallocated, compacted, or swapped in location as needed, improving the flexibility of the memory storage system. Furthermore, the general purpose memory pools described herein support both kernel (operating system) and user objects in the same pool areas, improving memory efficiency. Additional advantages of memory pooling as described in the present disclosure, in particular relating to memory pooling in a system using segment-addressed memory, are described below.
As illustrated in the example of
In addition, electronic computing device 100 comprises a processing unit 104. As mentioned above, a processing unit is a set of one or more physical electronic integrated circuits that are capable of executing instructions. In a first example, processing unit 104 may execute software instructions that cause electronic computing device 100 to provide specific functionality. In this first example, processing unit 104 may be implemented as one or more processing cores and/or as one or more separate microprocessors. For instance, in this first example, processing unit 104 may be implemented as one or more Intel Core 2 microprocessors. Processing unit 104 may be capable of executing instructions in an instruction set, such as the x86 instruction set, the POWER instruction set, a RISC instruction set, the SPARC instruction set, the IA-64 instruction set, the MIPS instruction set, or another instruction set. In a second example, processing unit 104 may be implemented as an ASIC that provides specific functionality. In a third example, processing unit 104 may provide specific functionality by using an ASIC and by executing software instructions.
Electronic computing device 100 also comprises a video interface 106. Video interface 106 enables electronic computing device 100 to output video information to a display device 108. Display device 108 may be a variety of different types of display devices. For instance, display device 108 may be a cathode-ray tube display, an LCD display panel, a plasma screen display panel, a touch-sensitive display panel, a LED array, or another type of display device.
In addition, electronic computing device 100 includes a non-volatile storage device 110. Non-volatile storage device 110 is a computer-readable data storage medium that is capable of storing data and/or instructions. Non-volatile storage device 110 may be a variety of different types of non-volatile storage devices. For example, non-volatile storage device 110 may be one or more hard disk drives, magnetic tape drives, CD-ROM drives, DVD-ROM drives, Blu-Ray disc drives, or other types of non-volatile storage devices.
Electronic computing device 100 also includes an external component interface 112 that enables electronic computing device 100 to communicate with external components. As illustrated in the example of
In the context of the electronic computing device 100, computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any tangible, non-transitory method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, various memory technologies listed above regarding memory unit 102, non-volatile storage device 110, or external storage device 116, as well as other RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the electronic computing device 100.
In addition, electronic computing device 100 includes a network interface card 118 that enables electronic computing device 100 to send data to and receive data from an electronic communication network. Network interface card 118 may be a variety of different types of network interface. For example, network interface card 118 may be an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., WiFi, WiMax, etc.), or another type of network interface.
Electronic computing device 100 also includes a communications medium 120. Communications medium 120 facilitates communication among the various components of electronic computing device 100. Communications medium 120 may comprise one or more different types of communications media including, but not limited to, a PCI bus, a PCI Express bus, an accelerated graphics port (AGP) bus, an Infiniband interconnect, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computer System Interface (SCSI) interface, or another type of communications medium.
Communication media, such as communications medium 120, typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media. Computer-readable media may also be referred to as computer program product.
Electronic computing device 100 includes several computer storage media (i.e., memory unit 102, non-volatile storage device 110, and external storage device 116). Together, these computer storage media may constitute a single data storage system. As discussed above, a data storage system is a set of one or more computer-readable data storage mediums. This data storage system may store instructions executable by processing unit 104. Activities described in the above description may result from the execution of the instructions stored on this data storage system. Thus, when this description says that a particular logical module performs a particular activity, such a statement may be interpreted to mean that instructions of the logical module, when executed by processing unit 104, cause electronic computing device 100 to perform the activity. In other words, when this description says that a particular logical module performs a particular activity, a reader may interpret such a statement to mean that the instructions configure electronic computing device 100 such that electronic computing device 100 performs the particular activity.
One of ordinary skill in the art will recognize that additional components, peripheral devices, communications interconnections and similar additional functionality may also be included within the electronic computing device 100 without departing from the spirit and scope of the present invention as recited within the attached claims.
The computing subsystem 200 includes a pair of microprocessors 202a-b and associated caches 203a-b communicatively connected to a memory subsystem 204 by a data bus 206. The microprocessors 202a-b and memory subsystem 204 are also, in the embodiment shown, communicatively connected to an I/O interface 208, for example providing an interface to remote storage (e.g., on a hard disk or remote memory system, or other system as described above in connection with
In the embodiment shown, the microprocessors 202a-b can be any of a number of types of programmable circuits, as described above in
The computing subsystem 200 illustrates an arrangement of a subsystem of an electronic computing system in which more than one programmable circuit (e.g., the microprocessors 202a-b) access the same, unified memory space using segment addressing. That is, the memory subsystem 204 can receive memory allocation requests from a microprocessor 202a-b or the I/O interface, with respect to any addressable memory space within the memory 212. The memory allocation requests can be of any of a variety of sizes, for example corresponding to one or more cache lines of one of the microprocessors. Other sizes of memory allocations or deallocations are possible as well.
For a memory allocation to successfully take place, an operating system is required to manage potential hardware conflicts between the components within the subsystem 200. For example, in the embodiments shown, microprocessors 202a and 202b cannot both access the same memory location at the same time; because each unallocated memory location is treated as an undifferentiated part of a unified memory, each memory allocation or deallocation causes a “lock”, preventing another microprocessor (or other processes executing on the same microprocessor) from accessing memory until the allocation or deallocation completes. By creating a pooled subsection of the memory space, and by assigning allocations of a particular size to a particular pool, only that pool must be locked during allocation or deallocation, allowing the other processor or process to access other memory areas during that allocation or deallocation, and avoiding the systemwide lock on memory resources.
Although in various embodiments of the present disclosure a wide variety of operating systems and hardware can be used, certain embodiments use segment-based memory addressing, such as is provided by the ClearPath MCP operating system provided by Unisys Corporation of Blue Bell, Pa. Other operating systems supporting segment-based memory addressing could be used as well.
Referring now to
The reserved memory block 302 can store any of a number of data objects associated with operation of the computing system implementing the memory management using memory pools as described herein. For example, the reserved memory block 302 can contain instructions or table relating to memory management or operation of a computing system that would be required prior to formation of memory pools. Alternatively, in certain embodiments, the reserved memory block 302 could itself be managed as a memory pool. For example, a memory pool could be created that includes particular requirements intended to accommodate operating system file information data structures or file data objects intended for or received from an I/O communication block (e.g. block 208 of
The memory pool areas 304 are each of a common size, and each have associated therewith a size class. The common size for each of the memory pool areas 304 relates to the overall footprint of the memory pool area, while the size class dictates the maximum size of a memory allocation that could occur from that memory pool area 304.
In the embodiment shown, four example memory pool areas 304a-d are shown, with a number of additional pool areas contemplated. Each memory pool area 304a-d has a common size, which is established prior to initial allocation of the memory pools. The common size can be any of a number of sizes; in an example embodiment, the memory pool areas can be any size up to 1022 words. Each pool area shown also has an associated size class. Memory pool areas 1 and 2 (304a and 304b) have a size class defined to be a single cache line (e.g. any single value defined by microprocessor characteristics, but typically about 8-512 bytes). Memory pool area 3 (304c) has a size class of 1022 words, and memory pool area 4 (304d) has a 20 word size class. In such an arrangement, memory pool area 304a and memory pool area 304b could be managed within a single memory pool, while memory pool area 304c and memory pool area 304d would be managed within separate memory pools from that pool relating to memory pool areas 304a-b. For example, for memory pool areas 304a-b, memory allocations of a cache line in size (or less, if a cache line memory size is determined to be the best fit size class memory pool in existence) could be allocated within either of the memory pool areas 304a-b, for example as determined using the memory management systems described below.
In certain embodiments, memory pools that include memory pool areas accommodating particular alignment requirements or non-portable memory requirements (e.g., certain system file related data objects) are referred to as “structure pools” which ensures that object sizes (described in
Non-pooled memory area 306 corresponds to a memory area managed by traditional segment addressing in which no memory pool areas are formed. The non-pooled memory area 306 can therefore accommodate memory allocation requests of sizes exceeding the maximum memory pool area size and/or exceeding the size class of all of the memory pools. Due to the existence of the memory pools 304a-d, the non-pooled memory area 306 will primarily be allocated in large blocks, reducing the probability of interspersed small memory allocations causing internal or external fragmentation issues.
Although, in the embodiment shown, only four memory pool areas are explicitly shown, it is understood that more or fewer memory pool areas could be included, and more or fewer memory pools could be defined with respect to those memory pool areas. The number and size of memory pools and memory pool areas is a matter of design choice, and will depend upon the typical workload and fragmentation experienced on a computing system. In general, a computing system executing workloads requiring large blocks of memory resources and relatively few small blocks of memory resources might require formation of fewer memory pools than a similar system requiring allocation of a larger number of small memory blocks (thereby increasing the chance that, due to allocations and deallocations, a small block straddles an open area in memory and causes checkerboarded memory unable to respond to subsequent allocation requests for large memory blocks).
Referring to
In the embodiment shown, the memory pool area 400 includes a pool area control data region 402 and a plurality of pool objects 404. The pool area control data region 402 includes information used to manage allocation of the objects within the region, such as a list of the available pool objects 406, a count of the available pool objects 408, and an Actual Segment Descriptor (ASD) number 410, locating the pool in memory. Other tracking information associating the memory pool area with a memory pool and with the objects stored within the memory pool area can be included as well.
Each of the plurality of pool objects 404 includes a fixed size storage area 420 that is available to be allocated in response to a request of that fixed size or smaller, depending upon whether the memory pool associated with the memory pool area 400 defines a size class that is a “best fit” for the request (i.e., barely large enough to accommodate the memory allocation request). The pool objects 404 also each include a set of management link words 422, which are used for locating the pool area control data region 402 during object deallocation (e.g., to update the list of available pool objects 406 and count of available pool objects 408).
The memory pool management system 500 includes a plurality of memory pool tracking structures 502 capable of tracking free and allocated memory space within each of the memory pools formed in a memory of a computing system. In the embodiment shown, the pool tracking structures include a plurality of lists of memory pool areas associated with a memory pool, with the lists indicating the status of those pools. For example, in the embodiment shown, the memory pool tracking structure 502 includes a full area list 504, a partial area list 506, and an empty area list 508. In certain embodiments, these lists 504-508 are implemented as doubly-linked lists of memory pool areas to allow for easy rearrangement of pool areas within the lists; in other embodiments, other memory structures (e.g., arrays, tables, or other types of linked lists) could be used. Additionally, each of the memory pool tracking structures 502 includes a set of pool parameters 510 tracking characteristics of the memory pool, such as: the size class of the memory pool areas in the memory pool, alignment requirements of the memory pool, offset information to a first pool object in the pool area, counters for each of the lists in the pool tracking structure, and other statistics. A particular embodiment of the memory pool tracking structure 502 includes the lists and parameters disclosed below in Table 1:
Additionally, in the embodiment shown, memory pool management system 500 includes a memory allocation module 512, a compaction module 514, an accounting module 516, and a reporting module 518. The memory allocation module 512 controls the method by which memory is allocated within the memory pools tracked by the memory pool tracking structures 502. For example, the memory allocation module 512 includes instructions that determine which memory pool to associate with a memory allocation request, and how to select a memory pool area from within that memory pool, as described in conjunction with
The compaction module 514 manages compaction and related pool area de-allocation and recycling procedures typically associated with garbage collection. Garbage collection refers to a memory management mechanism that automatically recycles allocated memory that is no longer in use. In the context of the present disclosure, garbage collection includes adding de-allocated memory to the available memory to be used, as well as movement of memory segments that are in use, where possible, to create larger free spaces.
In some embodiments, the compaction module 514 periodically performs compaction, pool area deallocation and recycling processes to maintain a minimum area reserved for the memory pools within the overall memory of the computing system. For example, the compaction process performed by the compaction module 514 involves moving allocated pool objects from a partially filled pool area into another partially filled pool area within the same memory pool. During this consolidation of pool objects, if a partially filled pool area becomes full, an entry identifying that pool area will be moved from the partial area list 506 to the full area list 504 associated with that memory pool, and parameters 510 will also be adjusted accordingly (e.g., by incrementing the number of full pools). Similarly, if a partially filled memory pool area becomes empty, an entry identifying that memory pool area will be moved from the partial area list 506 to the empty list 508, and parameters 510 will be adjusted (e.g., by decrementing the number of partially full pools).
The compaction module 512 can, in certain embodiments, utilize existing compaction and garbage collection services provided by a system memory manager, such as the WS_SHERIFF service within the ClearPath MCP operating system provided by Unisys Corporation of Blue Bell, Pa.
In certain embodiments, the compaction module 512 can be performed in a distributed manner, such that different processors within a computing system (e.g. as shown in
In certain embodiments, the compaction module 512 also manages pool area deallocation. By pool area deallocation, it is intended that an entire pool area could be released to become unallocated space to be managed by a generalized memory manager. This could be the case if compaction of memory pools leads to a buildup of empty pool areas (as indicated by the empty area list 508 of each of the memory pool tracking structures 502). If a preset threshold number of empty memory pool areas are found in the empty area lists, the compaction module 512 can remove those empty memory pool areas to add them to a global free list 520. The global free list 520 relates to pool areas that remain as pool areas, but could be reassigned to a different pool and use a different size class and other parameters, thereby reallocating the memory pool area to a different memory pool. This is possible due to the common size of memory pool areas for each of the memory pools.
Additionally, in certain embodiments, if a threshold of memory pool areas in the global free list 520 is exceeded, the compaction module 512 is configured to remove one or more memory pool areas from the global free list, thereby releasing the space held by the pool to allow it to be deallocated and reallocated by the systemwide memory manager in response to other memory allocation requests. In certain embodiments, the compaction module 512 is configured to adjust the threshold at which empty memory pools are deallocated and returned to the system, for example, by lowering the number of empty memory pool areas maintained upon detection of low memory resources systemwide. Other embodiments are possible as well.
The accounting module 516 provides memory utilization accounting to collect statistics regarding memory pool usage. This information would be used to tune the memory pools that are allocated during future usage. For example, although in certain embodiments memory pools and associated memory pool areas are allocated as needed based on requests that are used to define the size and size class of those pools, in certain embodiments, pool areas can be preallocated, based at least in part on historical observations regarding the size of the memory pools and the size class of pool objects to be stored therein.
Additionally, a reporting module 518 allows reporting and display of memory pool usage for monitoring by a user. Various pieces of information could be extracted for display alongside other operational parameters of a computing system, such as the available pools, in use pools, fragmentation statistics, and other information.
A pool identification operation 604 identifies an appropriately sized pool to accommodate the memory allocation request. The pool identification operation 604 will select a “best fit” memory pool to be associated with the allocation request. Preferably, a memory pool has a size class that matches the allocation request; if this is not the case, a closest memory pool could be selected having a size class slightly larger than the allocation request, to accommodate the request. The pool identification operation 604 will identify either a size pool or structure pool depending on the particular identified memory request as well.
A pool lock operation 606 will lock the selected memory pool to prevent other processes or systems from accessing the particular memory pool until the allocation successfully completes. Notably, the pool lock operation 606 prevents access of any of the memory pool areas associated with the memory pool (e.g., as identified by the memory pool tracking structure 502 associated with that memory pool). Other memory, including other memory pools, are accessible to other processes and resources within the computing system during memory allocation method 600.
A pool area location operation 608 locates an appropriate memory pool area from which to allocate memory. To minimize fragmentation, preferably a memory pool area that is partially free will be selected prior to selection of a free memory pool, to prevent creation of two (or more) partially free memory pool areas. If no partially free pool areas area available, an empty pool area can be used. If no empty pool areas exist as well, the pool area location operation can allocate a new pool area, for example from the global free list 520 of
Following location of the pool area, the availability of the memory pool and status of the memory pool are updated. Specifically, a head entry update operation 610 removes the head entry from the list of available pool objects within the memory pool area (e.g., the list of the available pool objects 406 as illustrated in
Once the pool parameters are updated and the pool object is allocated, an unlock operation 618 unlocks the memory pool, allowing other processes or systems to access the memory reserved as used by the memory pool. An end operation 620 signifies completion of a memory allocation.
The method 700 is instantiated at a start operation 702, which corresponds to receiving a request at a memory pool management system to deallocate memory within one of the managed memory pools. An object location operation 704 determines whether the object is present in a memory pool. If it is determined that the object is present in a memory pool, a pool area determination operation 706 determines which memory pool area within a memory pool contains the object. Once the memory pool area is located, a memory pool identification module 708 identifies the memory pool as requiring action. A lock operation 710 locks the memory pool (but not other portions of memory, as discussed with respect to lock operation 606 of
Following location of the pool area, the availability of the memory pool and status of the memory pool are updated.
A pool increment operation 712 increments the total number of pool objects available in the pool (e.g., the overall available count illustrated in Table 1, above). A pool area increment operation 714 decrements the count of available pool objects (e.g., the count of the available pool objects 408 of
Once the pool parameters are updated and the pool object is allocated, an unlock operation 720 unlocks the memory pool, allowing other processes or systems to access the memory reserved as used by the memory pool. An end operation 722 signifies completion of a memory deallocation.
Although a number of the operations of
Referring now to
Therefore, the system memory manager has fewer memory areas to track, since it tracks a pool as a single object, rather than a large number of small memory objects. Additionally, allocation time can be reduced in such an instance by an estimated 43% using a single threaded test allocating 500,000 events (a small data structure common during execution within a ClearPath MCP system).
Overall, it can be seen that a number of advantages exist relating to use of memory pools in a segmented memory system, according to the principles of the present disclosure. For example, memory allocation times decrease while maintaining management of fragmentation issues. Additionally, memory lock effects can be isolated to a single memory pool, reducing latencies caused by memory requests occurring during memory allocation/deallocation processes. Additional benefits are provided as well, as previously described.
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.