Patent Application
20060059318
In a computer system, such as a server, multiple processes may be running concurrently. These processes share the physical memory of the computer system for their memory needs. With reference to
Paging, as is known, involves swapping the contents of physical memory into and out of disk-based storage, such as a hard drive to extend the logical memory available to a process. Because the memory access speed for disk-based storage is significantly slower than for semiconductor-based storage, paging affects the execution speed of the process being paged.
In some cases, it is desirable to guarantee a certain amount of physical memory to a process or a group of processes. In the prior art, different approaches have been taken to ensure that a process or a group of processes has a guaranteed amount of physical memory during execution. The brute force approach involves having a process lock down a certain amount of physical memory, which may then only be used by that particular process. Although this approach ensures that the process will have a guaranteed amount of physical memory, it is inefficient since other processes cannot utilize memory that is locked even if the process that locks down that memory does not truly need all of it at all times for its execution. Secondly, memory locking is a privileged operation that is not available to ordinary applications.
Another approach based on the external page-cache management scheme lets processes have direct control over their share of physical memory through special primitives provided by the operating system. A sophisticated application can exploit this feature to implement a dedicated memory management policy that best suits its requirements. However, this approach is not backward compatible with existing applications since a legacy application may not be aware of such primitives and would be at a disadvantage when executing in an environment wherein other applications directly control their physical memory requirements.
Another approach involves using a special application program to manage physical memory consumption. This program, known as the Resource Manager, queries the operating system periodically to determine the amount of physical memory being used by every process on the system. When the available memory on the system is low the Resource Manager picks processes that are exceeding their share and tries to force them to shrink in size. This is achieved by stopping the selected processes via signals and process priority changes and then relying on the system memory pager to reclaim non-recently referenced pages of physical memory. In this form of control all of the necessary logic is implemented by the Resource Manager program, a user application, and does not require any modifications to the operating system. However, it is not very deterministic and problems can arise, for instance, if a target process has set up its own signal handlers to ignore signals sent from the Process Resource Manager.
Memory resource grouping represents another approach to address the physical memory control issue. In memory resource grouping, the physical memory is divided into logical blocks called MRGs. Referring now to
Memory resource grouping also has other advantages. A MRG (such as MRG 136) can be set up to import from another MRG or export memory to another MRG. This form of controlled sharing allows the resources of an under-utilized MRG (that is willing to export) to be used by an over-loaded MRG (that has import capability), leading to higher overall physical memory utilization on the computer system.
Unfortunately, memory resource grouping has only been applied thus far to private memory of processes. To further explain this issue,
Kernel memory refers to the memory used by the operating system kernel. User resource types refer to the various memory types that may be involved with process execution. For example, process private memory 206 includes the data memory, stack or heap memory specific to a process during execution. Local shared memory 208 may include, for example, a memory-mapped file segment that is shared between specific processes.
Shared text memory 210A may include, for example, text that is shared by identical copies of programs executing in a computer system (i.e., such global shared memory is not specific to any process or groups of processes). Likewise, shared library memory 210B may include, for example, certain libraries of code that are shared by all processes executing in a computer system.
As shown in
As mentioned, the paradigm of grouping memory in different MRGs has been confined to private memory thus far. Partitioning private memory is less complicated than partitioning local shared memory or partitioning global shared memory since each private memory segment (or object) is affiliated with only one process. As currently implemented, it is not possible to extend memory resource grouping to either local shared memory or global shared memory.
To elaborate, consider the situation in
Process 302 creates three private segments 302A, 302B, and 302C during execution. These private segments are automatically affiliated (by the operating system) with the MRG 352 since there is a private affiliation 312 between process 302 and MRG 352. Accordingly, the memory required by memory segments 302A, 302B, and 302C are allocated only from MRG 352.
Likewise, process 304 creates three private segments 304A, 304B, and 304C during execution. These private segments are automatically affiliated (by the operating system) with the MRG 354 since there is a private affiliation 314 between process 304 and MRG 354. Accordingly, the memory required by memory segments 304A, 304B, and 304C are allocated only from MRG 354. Logically speaking, each of process 302 and process 304 has been partitioned to use only the memory associated with the MRG to which it is affiliated for its private memory needs (i.e., MRG 352 for process 302 and MRG 354 for process 304).
Now consider the shared memory situation. If process 302 and process 304, which are affiliated with different MRGs for their private memory needs, need to share a memory segment (i.e., either local shared memory or global shared memory), a methodology needs to exist to allow these processes to share a memory segment across the logical partitions that divide the MRGs. Furthermore, a methodology needs to be developed to allow a shared memory segment (either local or global) to be shared by processes even if the process that created that shared memory segment detaches from it or no longer exists. This is unlike the situation with a private memory segment wherein the private memory segment is deallocated if it is detached from its creator process or if its creator process terminates.
Additionally, the sharing needs to be transparent from the load-balancing perspective in that it is important to be able to move a process from one MRG to another MRG without undue restriction even if that process shares a memory segment with another process that may be assigned to any of the MRGs. For example, requiring that processes sharing a memory segment to be assigned to the same MRG would ensure that these processes can share the same memory segment but would impose an undue restriction on the ability to move a process from one MRG to another MRG during load balancing. For backward compatibility reasons, the methodology also needs to work within the existing application semantics and memory resource grouping infrastructure.
The invention relates, in one embodiment, to a method for allocating memory associated with a local shared memory segment to facilitate execution of a first process. The method includes automatically allocating memory associated with a first MRG to the local shared memory segment if the local shared memory segment is created by the first process. The first MRG is associated with a first local shared affiliation that involves the first process. The method also includes automatically allocating memory associated with a second MRG to the local shared memory segment if the local shared memory is created by a second process different from the first process. The second MRG is associated with a second local shared affiliation that involves a second process.
In another embodiment, the invention relates to a method for allocating memory associated with a global shared memory segment to facilitate execution of a first process. The method includes ascertaining a global shared affiliation having the same memory resource type as a memory resource type associated with the global shared memory segment, with the global shared affiliation involving a first MRG. The method further includes allocating memory from the first MRG to the global shared memory segment to facilitate execution of the first process.
In yet another embodiment, the invention relates to a method for allocating memory associated with a global shared memory segment to facilitate execution of a first process. The method includes ascertaining a first global shared affiliation involving a first MRG. The first global shared affiliation has the same memory resource type as a memory resource type associated with the global shared memory segment. The first global shared affiliation is different from other global shared affiliations that have the same memory resource type as the memory resource type associated with the global shared memory segment by virtue of an association indicia that is also associated with the first process. The method includes allocating memory from the first MRG to the global shared memory segment to facilitate execution of the first process.
These and other features of the present invention will be described in more detail below in the detailed description of the invention and in conjunction with the following figures.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
The present invention will now be described in detail with reference to a few embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention.
Various embodiments are described herein below, including methods and techniques. It should be kept in mind that the invention might also cover articles of manufacture that includes a computer readable medium on which computer-readable instructions for carrying out embodiments of the inventive technique are stored. The computer readable medium may include, for example, semiconductor, magnetic, opto-magnetic, optical, or other forms of computer readable medium for storing computer readable code. Further, the invention may also cover apparatuses for practicing embodiments of the invention. Such apparatus may include circuits, dedicated and/or programmable, to carry out tasks pertaining to embodiments of the invention. Examples of such apparatus include a general purpose computer and/or a dedicated computing device when appropriately programmed and may include a combination of a computer/computing device and dedicated/programmable circuits adapted for the various tasks pertaining to embodiments of the invention.
In accordance with embodiments of the present invention, there are provided methods and arrangements for allowing processes to share local shared memory segments and to share global shared memory segments without impacting the ability to partition processes among MRGs and without placing undue restrictions on the ability to load-balance among MRGs. In an embodiment, if a process creates a local shared memory segment, that local shared memory segment is allocated memory from the MRG that is associated with the creator process.
In the context of local shared memory, the association between a process and a MRG is governed, as will be seen, by a shared affiliation that is established for the process either by inheritance or by the operator of the computer system.
To elaborate, when the computer system starts up, the first process that executes may employ memory from a default MRG. This default MRG occupies the entire available physical memory until another MRG is created (e.g., by the system administrator), causing the two MRGs to share the available physical memory. Furthermore, processes that startup may be defaulted to the default MRG unless they are reassigned (via the affiliation mechanism) to another MRG. With respect to inheritance, a child process that forks from a parent process inherits the affiliations of the parent process. Forking is a concept well known in unix and will not be discussed in details herein.
Further, note that affiliations are type-specific, i.e., an affiliation is specific as to the memory resource type. For example, a process may have its private affiliation with one MRG and a shared affiliation with another MRG. Global shared memory, on the other hand, is not specific to any process since by definition, the global shared memory may be shared by any process. Accordingly, there exists, as will be shown later herein, a global shared affiliation for each global shared memory resource type. However, there is no creator process for a global shared memory segment in the same sense that there is a creator process for a local shared memory segment.
In the current example, if a second process wishes to share that local shared memory segment, memory for such sharing by the second process is allocated not from the MRG associated with (by virtue of the local shared affiliation mechanism) that second process but from the MRG associated with (again, by virtue of the local shared affiliation mechanism) the process that created that local shared memory segment. In this manner, many different processes having shared affiliations with different MRGs can still share a particular local shared memory segment, and all memory required for such sharing is allocated from the MRG associated with (by virtue of the local shared affiliation mechanism) the process that created that shared memory segment. Furthermore, these sharing processes may be moved among MRGs of the computer system (e.g., for load balancing) without impacting the ability to continue sharing the local shared memory segment.
If the process that created a local shared memory segment detaches from that local shared memory segment or terminates, the local shared memory segment is considered to be orphaned. The orphan concept allows sharing to continue and, as will be discussed, load-sharing to occur. In this case, the orphaned local shared memory segment is allowed to continue to use the memory of the MRG that is affiliated with the process that created that local shared memory segment.
Furthermore, embodiments of the invention provide a facility to allow the system administrator to ascertain the orphaned local shared memory segments in a given MRG, as well as a facility to allow the system administrator to move orphaned local shared memory segments from one MRG to another MRG for load-balancing purposes.
With respect to global shared memory, since a global shared memory resource type may be shared by any process and is not affiliated with any particular process or group of processes, the global shared memory segments of that resource type may be associated with (by virtue of a global shared affiliation) a particular MRG. Any process may share a global shared memory segment by attaching to it, irrespective of its own private and/or local shared affiliations. Memory required for such sharing is allocated out of the MRG affiliated with (by virtue of the global shared affiliation mechanism, which is created by the operator of the computer system) the resource type to which the global shared memory segment belongs. The same facilities that exist to allow a process to move orphaned local shared memory segments among MRGs may be employed to manage the global shared memory.
The invention may be better understood with reference to the figures and discussions herein.
Likewise,
If local shared memory segment 402 is configured to be shared between creator process 302 and process 304, process 304 may share that shared local memory segment 402. However, memory allocation for such sharing by process 304 is performed using the memory of MRG 406, i.e., the MRG associated with the local shared affiliation involving the process that originally created the local shared memory segment. Note that this is the case despite the fact that process 304 has a local shared affiliation 426, which affiliates process 304 with MRG 354 for local shared memory. The memory allocation to accommodate the sharing by process 304 of local shared memory segment 402 is not made from MRG 354 since MRG 354 is not associated with the local shared affiliation that involves the creator process of local shared memory segment 402 (i.e., creator process 302).
Other processes may share local shared memory segment 402 in the same manner and have the memory allocation therefor performed using memory from MRG 406. If process 302 detaches from shared local memory segment 402 or terminates, local shared memory segment 402 continues to exist in MRG 406 and may continue to be shared as an orphaned local shared memory segment among the other processes. This is shown in
In an embodiment, a local shared memory segment includes attributes that allows it to be identified as an orphaned memory segment to a primitive (i.e., command) querying about the existence of such orphaned memory segments in a MRG. An application programming interface (API) is provided to extract this information from the kernel. Furthermore, an API is also provided to allow a system administrator to move all orphaned local shared memory segments from one MRG to another MRG (e.g., for load balancing purposes). The linkage between a process sharing an orphaned local shared memory segment and that local shared memory segment is maintained when an orphaned local shared memory segment is moved from one MRG to another MRG, thereby allowing process execution to continue.
In this manner, logical partitioning of processes to different MRGs may be maintained even if these processes share one or more local shared memory segments. Such logical partitioning makes it possible to guarantee a certain process or group of processes a certain amount of physical memory during execution. Additionally, the orphan concept allows sharing to continue even if the process that created a local shared memory segment subsequently terminates or detaches from that local shared memory segment. Furthermore, since the linkage between a process and a local shared memory segment is maintained if the process is moved from one MRG to another MRG, the ability of the computer system to load balance among MRGs is not impacted.
Thereafter, a process such as process 610 may create a plurality of private memory segments 612 and 614 in the manner described earlier. Process 610 may also create a global shared memory segment 616 that consumes the shared text memory resource type. The allocation for this sharing is made from MRG 604 since there is an affiliation of the same memory resource type text (i.e., shared text affiliation 602) to MRG 604.
Process 610 may also create a global shared memory segment 618 that consumes the shared library code memory resource type. The allocation for this sharing is made from MRG 608 since there is an affiliation of the same memory resource type library code (i.e., shared library code affiliation 606) to MRG 608.
In the example of
For example, if two different shared text objects (e.g., binary code A and binary code B) are affiliated with two different MRGs (e.g., MRG 1 and MRG 2 respectively), the decision regarding which MRG to employ for allocation when a process creates a shared text memory segment involves not only ascertaining the global affiliation of the memory type text but also involves at least one other association criteria. This is because ascertaining only the global affiliation of the memory type text would result in two possible answers: MRG1 and MRG2. The name of the application may be the other association criteria. For example, if it is desired that any process sharing any or all of binary code A be allocated memory from MRG1, the method applies the additional association criteria (i.e., the identity of binary code A) to resolve the MRG from which allocation should be made.
As mentioned, an API may be provided to facilitate moving orphaned local shared memory segments among MRGs. The same API and facility may be employed to facilitate moving global shared memory objects among MRGs. For example, the system administrator may employ a primitive to move all shared text segments from one MRG to another MRG.
MRG_GET_PROC_AFF is employed to obtain the MRG affiliations of a process (for private memory and local shared memory). MRG_SET_PROC_AFF allows a system administrator or an operator to change the MRG affiliations for a process (e.g., changing the inherited or default affiliations of a process). MRG_GET_OBJ_AFF allows a system administrator or an operator to obtain the current affiliations of global shared memory, such as shared text and shared library code. MRG_SET_OBJ_AFF allows a system administrator or an operator to change the global shared memory affiliations (shared text and/or shared library code) as well as re-locate orphaned local shared memory objects from one MRG to another. MRG_NUM_OBJ allows a system administrator or an operator to obtain the number of objects associated with a MRG. The objects returned by MRG_NUM_OBJ are sorted by memory type (e.g., private, local shared, global text, global library code, etc.) and for local shared memory segments, whether they are orphaned.
As can be appreciated from the foregoing, the invention provides various techniques for permitting processes to be partitioned in different MRGs to share local and global shared memory. In combination with the prior art management of private memory partitioning, a complete solution now exists for partitioning memory for all user memory types (private, local shared, and global shared) within the existing MRG infrastructure. No change to the unix semantics is required, thereby rendering the inventive techniques fully backward compatible with existing unix applications. The affiliations created permit full load-balancing capabilities with respect to the processes. Embodiments of the invention permit the sharing to continue even if the process that creates the local shared memory segment detaches or terminates. Furthermore, facilities are provided to allow the system administrator, to assign affiliations, to query for orphaned local shared memory segments, and to load balance by moving local orphaned local memory segments or global shared memory segments among MRGs.
While this invention has been described in terms of several embodiments, there are alterations, permutations, and equivalents, which fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention.
