A system, computer-readable storage medium storing at least one program, and a computer-implemented method for dynamically allocating memory for processes is presented. A first request to allocate memory for a first process is received, where the first process is associated with a first quality-of-service class in a plurality of quality-of-service classes. A first memory allocation for the first quality-of-service class is calculated as a function of a current amount of free memory on the server and a first minimum memory allocation for the first quality-of-service class. An amount of memory currently used by processes associated with the first quality-of-service class is determined. The first request is rejected when the amount of memory currently used by the processes associated with the first quality-of-service class is greater than or equal to the first memory allocation.
|
17. A non-transitory computer readable storage medium storing at least one program configured for execution by at least one processor of a computer system, the at least one program comprising instructions to:
receive a first request to allocate memory for a first process, the first process being associated with a first quality-of-service class in a plurality of quality-of-service classes;
calculate a first memory allocation for the first quality-of-service class as a function of a current amount of free memory on the server and a first minimum memory allocation for the first quality-of-service class;
determine an amount of memory currently used by processes associated with the first quality-of-service class; and
reject the first request when the amount of memory currently used by the processes associated with the first quality-of-service class is greater than or equal to the first memory allocation.
12. A system to dynamically allocate memory for processes, comprising:
at least one processor;
memory; and
at least one program stored in the memory and executable by the at least one processor, the at least one program comprising instructions to:
receive a first request to allocate memory for a first process, the first process being associated with a first quality-of-service class in a plurality of quality-of-service classes;
calculate a first memory allocation for the first quality-of-service class as a function of a current amount of free memory on the server and a first minimum memory allocation for the first quality-of-service class;
determine an amount of memory currently used by processes associated with the first quality-of-service class; and
reject the first request when the amount of memory currently used by the processes associated with the first quality-of-service class is greater than or equal to the first memory allocation.
1. A computer-implemented method for dynamically allocating memory for processes, performed on a server having at least one processor and memory storing at least one program for execution by the at least one processor to perform the method, comprising:
receiving a first request to allocate memory for a first process, the first process being associated with a first quality-of-service class in a plurality of quality-of-service classes;
calculating a first memory allocation for the first quality-of-service class as a function of a current amount of free memory on the server and a first minimum memory allocation for the first quality-of-service class;
determining an amount of memory currently used by processes associated with the first quality-of-service class; and
rejecting the first request when the amount of memory currently used by the processes associated with the first quality-of-service class is greater than or equal to the first memory allocation.
2. The computer-implemented method of
calculating a second memory allocation for the first process as a function of a current amount of free memory in the first memory allocation;
determining an amount of memory currently used by requests associated with the first process in the first quality-of-service class; and
rejecting the first request when the amount of memory used by the requests associated with the first process in the first quality-of-service class is greater than or equal to the second memory allocation.
3. The computer-implemented method of
4. The computer-implemented method of
accepting the first request;
increasing the first memory allocation to accommodate the first request; and
increasing the second memory allocation to accommodate the first request.
5. The computer-implemented method of
determining that the first request has been terminated;
releasing memory allocated to the first request in the first memory allocation; and
releasing memory allocated to the first request in the second memory allocation.
6. The computer-implemented method of
7. The computer-implemented method of
calculating a respective free memory allocation for the respective quality-of-service class as a product of a respective free memory multiplier for the respective quality-of-service class and the current amount of free memory on the server;
calculating a respective candidate memory allocation for the respective quality-of-service class as a sum of the respective free memory allocation and the respective minimum memory allocation for the respective quality-of-service class; and
calculating the respective memory allocation as a minimum of the respective candidate memory allocation for the respective quality-of-service class and a predetermined amount of memory.
8. The computer-implemented method of
9. The computer-implemented method of
10. The computer-implemented method of
11. The computer-implemented method of
13. The system of
calculate a second memory allocation for the first process as a function of a current amount of free memory in the first memory allocation;
determine an amount of memory currently used by requests associated with the first process in the first quality-of-service class; and
reject the first request when the amount of memory used by the requests associated with the first process in the first quality-of-service class is greater than or equal to the second memory allocation.
14. The system of
15. The system of
calculate a respective free memory allocation for the respective quality-of-service class as a product of a respective free memory multiplier for the respective quality-of-service class and the current amount of free memory on the server;
calculate a respective candidate memory allocation for the respective quality-of-service class as a sum of the respective free memory allocation and the respective minimum memory allocation for the respective quality-of-service class; and
calculate the respective memory allocation as a minimum of the respective candidate memory allocation for the respective quality-of-service class and a predetermined amount of memory.
16. The system of
18. The non-transitory computer readable storage medium of
calculate a second memory allocation for the first process as a function of a current amount of free memory in the first memory allocation;
determine an amount of memory currently used by requests associated with the first process in the first quality-of-service class; and
reject the first request when the amount of memory used by the requests associated with the first process in the first quality-of-service class is greater than or equal to the second memory allocation.
19. The non-transitory computer readable storage medium of
accept the first request;
increase the first memory allocation to accommodate the first request; and
increase the second memory allocation to accommodate the first request.
20. The non-transitory computer readable storage medium of
determine that the first request has been terminated;
release memory allocated to the first request in the first memory allocation; and
release memory allocated to the first request in the second memory allocation.
|
This application claims priority to U.S. Provisional Application No. 61/618,547, filed Mar. 30, 2012, which is incorporated by reference herein in its entirety.
The disclosed embodiments relate generally to allocating memory for processes.
Memory on a server is a limited resource that is shared by all processes executing on the server. A memory management system of the server handles requests to allocate memory to processes based on an amount of free memory on the server. The memory management system also releases memory when processes no longer need the memory. Unfortunately, existing memory management systems do not account for quality-of-service requirements of the processes when allocating memory to the processes. For example, consider a first request to allocate memory to a first process and a second request to allocate memory to a second process. Assume that the first request is received before the second request. Also assume that the second request has a higher quality-of-service requirement than the first process. In other words, the resources of the server should be prioritized for use by the second process before the first process. However, since the first request is received before then second request, the memory management system allocates memory to the first process. If the amount of free memory on the server is low, there might not be enough memory to allocate to the second process when the second request is received. Thus, the quality-of-service requirement of the second process may not be achieved.
The embodiments disclosed herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. Like reference numerals refer to corresponding parts throughout the drawings.
Note that although
In some implementations, a respective request to allocate memory for a respective process includes a desired memory allocation for the respective process. For example, the respective request may be a request to increase a memory allocation for the respective process in order to accommodate additional data and/or commands to be processed by the respective process.
In some implementations, a respective request to allocate memory for a respective process is associated with data and/or commands to be processed by the respective process. For example, the respective request may be a handshake operation between the computer system 104-1 and the server 102 in which the computer system 104-1 issues the respective request to the server 102 to allocate memory to the respective process on the server 102. If the respective request is accepted by the server 102 (e.g., by transmitting a message to the computer system 104-1 indicating that the server 102 has accepted the respective request), the computer system 104-1 may then transmit the data and/or the commands to be processed by the process.
In some implementations, the server 102 accepts or rejects a respective request to allocate memory for a respective process that is associated with a respective quality-of-service class based on a current amount of free memory on the server 102 and a respective minimum memory allocation for the respective quality-of-service class. These implementations are described in more detail below with reference to
In some implementations, the server 102 calculates memory allocations for quality-of-service classes as a function of a current amount of free memory on the server 102 and minimum memory allocations for the quality-of-service classes. For example, in some implementations, the server 102 calculates a respective memory allocation (Ai) for a respective quality-of-service class i as follows: Ai=min(CRi+CMi*F, M), where CRi is a respective minimum memory allocation for the respective quality-of-service class, CMi is a respective free memory multiplier for the respective quality-of-service class, and F is the amount of free memory (e.g., unused memory) of the server 102. A respective minimum memory allocation (CRi) for a respective quality-of-service class i is an amount of the memory 302 that is guaranteed to be allocated to processes associated with the respective quality-of-service class i when (1) the processes associated with the respective quality-of-service class i requests it and (2) a current amount of memory used (Ui) by the respective quality-of-service class i is less than the respective minimum memory allocation (CRi) for a respective quality-of-service class i. In other words, a current amount of memory used (Ui) by the respective quality-of-service class i may be less than the respective minimum memory allocation (CRi) for the quality-of-service class i, but may increase to at least the respective minimum memory allocation (CRi) for the quality-of-service class i should the processes associated with the respective quality-of-service class i require the memory. Similarly, the current amount of memory used (Ui) by the respective quality-of-service class i may be less than the respective memory allocation (Ai) for the respective quality-of-service class i, but may increase to at most the respective memory allocation (Ai) for the respective quality-of-service class i should the processes associated with the respective quality-of-service class require the memory. However, note that since the respective memory allocation (Ai) for the respective quality-of-service class i is a function of the amount of free memory F on the server 102, the value of the respective memory allocation (Ai) for the respective quality-of-service class i changes as memory is allocated to and released by processes on the server 102. Example values for CRi and CMi are illustrated in
In
In
In
In
In
In some implementations, the processes discussed with reference to
In some implementations, when a request to allocate memory to a process associated with a quality-of-service class was accepted and later becomes terminated (e.g., the operations associated with the request have been terminated or completed), the server 102 releases memory allocated to the request in the quality-of-service class. In other words, the server 102 releases the memory allocated to accommodate the request in the memory allocation for quality-of-service class. Stated another way, since the request has been terminated, the memory previously used by the request is no longer needed and the server 102 releases the memory allocated to the request in the memory allocation for the quality-of-service class. Note that these implementations may also be applied to release memory allocated to accommodate the request in any level (and/or multiple levels) of the memory allocation hierarchy (e.g., a memory allocation for a quality-of-service class, a memory allocation for a process within the memory allocation for the quality-of-service class, a memory allocation for a thread within the memory allocation for the process that is within the memory allocation for the quality-of-service class, etc.). In some implementations, when memory has been hierarchically allocated to accommodate the request in multiple levels of the memory allocation hierarchy, the server 102 releases the memory allocated to accommodate the request at each level of the memory allocation hierarchy after the server 102 determines that the request has been terminated. For example, assume that the memory allocation hierarchy includes two levels: a quality-of-service class level and a process level. Thus, in these implementations, the server 102 releases the memory allocated to accommodate the request at both of these levels (the quality-of-service class level and the process level) after the server 102 determines that the request has been terminated. In some implementations, the server 102 releases the memory allocated to accommodate the request in reverse hierarchical order from the deepest level of the memory allocation hierarchy to the highest level of the memory allocation hierarchy. In the previous example, the server 102 first releases the memory allocated to accommodate the request from the process level and then releases the memory allocated to accommodate the request from the quality-of-service class level.
In some implementations, the minimum memory allocation (CRi) is omitted from the calculation of the memory allocation for the quality-of-service class (Ai). For example, Ai may be calculated as follows: Ai=min (CMi*F, M). In another example, Ai may be calculated as follows: Ai=CMi*F.
In some embodiments, the programs or modules identified above correspond to sets of instructions for performing a function described above. The sets of instructions can be executed by one or more processors (e.g., the CPUs 402). The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures or modules, and thus various subsets of these programs or modules may be combined or otherwise re-arranged in various embodiments. In some embodiments, memory 302 stores a subset of the modules and data structures identified above. Furthermore, memory 302 may store additional modules and data structures not described above.
Although
In some embodiments, the programs or modules identified above correspond to sets of instructions for performing a function described above. The sets of instructions can be executed by one or more processors (e.g., the CPUs 502). The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures or modules, and thus various subsets of these programs or modules may be combined or otherwise re-arranged in various embodiments. In some embodiments, memory 510 stores a subset of the modules and data structures identified above. Furthermore, memory 510 may store additional modules and data structures not described above.
Although
Dynamically Allocating Memory for Processes
The memory allocation module 418 calculates (604) a first memory allocation for the first quality-of-service class as a function of a current amount of free memory on the server (F) and a first minimum memory allocation (CR1) for the first quality-of-service class. In some implementations, a sum of a minimum memory allocation for each quality-of-service class in the plurality of quality-of-service classes is no greater than a total amount of memory on the server 102.
The memory allocation module 418 determining (606) an amount of memory currently used (U1) by processes associated with the first quality-of-service class.
When the amount of memory currently used (U1) by the processes associated with the first quality-of-service class is greater than or equal to the first memory allocation (608, yes), the memory allocation module 418 rejects (610) the first request. For example, the memory allocation module 418 may transmit a message (or cause a message to be transmitted) to a computer system that issued the request (e.g., the computer system 104-1) notifying the computer system that the first request was rejected. In some implementations, the computer system retransmits the first request to the server 102 after a predetermined time period has elapsed since a prior transmission of the first request to the server 102. In some implementations, the computer system transmits the first request to another server that is capable of servicing the first request. For example, the computer system may transmit the first request to a server in another server cluster.
In some implementations, the memory allocation module 418 performs operations to verify whether accepting the first request will cause the memory used by the first process (e.g., the process associated with the first request) in the first memory allocation for the first quality-of-service class to exceed the memory allocation for the first process in the first quality-of-service class. In these implementations, the memory allocation module 418 calculates (612) a second memory allocation (AP1) for the first process (P1) as a function of a current amount of free memory (F1) in the first memory allocation and determines (614) an amount of memory currently used by requests associated with the first process in the first quality-of-service class. In some implementations, the current amount of free memory (F1) in the first memory allocation (e.g., the memory allocation A1 for the first quality-of-service class) is a difference of the first memory allocation (A1) and the amount of memory currently used by processes associated with the first quality-of-service class (U1).
When the amount of memory used (Ui) by the requests associated with the first process (P1) in the first quality-of-service class is greater than or equal to the second memory allocation (AP1) (616, yes), the memory allocation module 418 then rejects (618) the first request. For example, the memory allocation module 418 may transmit a message (or cause a message to be transmitted) to a computer system that issued the request (e.g., the computer system 104-1) notifying the computer system that the first request was rejected. In some implementations, the computer system retransmits the first request to the server 102 after a predetermined time period has elapsed since a prior transmission of the first request to the server 102. In some implementations, the computer system transmits the first request to another server that is capable of servicing the first request. For example, the computer system may transmit the first request to a server in another server cluster.
When the amount of memory used (UP1) by the requests associated with the first process (P1) in the first quality-of-service class is less than the second memory allocation (AP1) (616, no), the memory allocation module 418 accepts (620) the first request, increases (622) the first memory allocation to accommodate the first request and increases (624) the second memory allocation to accommodate the first request.
In some implementations, instead of performing operations 620-624 at the process level of the memory allocation hierarchy, the memory allocation module 418 performs at least one other level of memory allocation operations. For example, the memory allocation module 418 may verify whether accepting the first request will cause the memory used by a first thread of the first process (e.g., the thread of the process associated with the first request) in the second memory allocation for the first process (which is in the first memory allocation for the first quality-of-service class) to exceed the memory allocation for the first thread of the first process in the memory allocation for the first thread (which is in the second memory allocation for the first process, which itself is in the first memory allocation for the first quality-of-service class). In other words, the memory allocation module 418 performs operations analogous to operations 612-624, but at the thread level. In some implementations, the memory allocation module 418 hierarchically repeats the operations discussed above with reference to
In some implementations, when the amount of memory currently used (U1) by the processes associated with the first quality-of-service class is less than the first memory allocation (A1) (608, no), the memory allocation module 418 accepts the first request and increases the first memory allocation to accommodate the first request. Thus, in these implementations, the memory allocation module 418 does not perform any further operations to verify (i) whether accepting the first request will cause the memory used by the first process (e.g., the process associated with the first request) in the first memory allocation for the first quality-of-service class to exceed a memory allocation for the first process in the first memory allocation for first-quality-of-service class, (ii) whether accepting the first request will cause the memory used by a first thread of the first process (e.g., the thread of the process associated with the first request) in the memory allocation for the first process (which is in the memory allocation for the first quality-of-service class) to exceed the memory allocation for the first thread of the first process in the memory allocation for the first thread (which is in the memory allocation for the first process, which itself is in the first memory allocation for the first quality-of-service class), and so on. In other words, in these implementations, the memory allocation module 418 does not perform operations 612-624.
The benefits of the implementations described above include (1) the server 102 maintains high utilization of memory without sacrificing prioritization between quality-of-service classes and (2) the server 102 can dynamically adjust the memory allocations for the quality-of-service classes (processes, threads, etc.) based on the current amount of memory used (and/or the current amount of free memory) on the server 102.
Note that although the discussion above refers to the memory allocation module 418 performing the operations illustrated in
The methods illustrated in
Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the implementation(s). In general, structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the implementation(s).
It will also be understood that, although the terms “first,” “second,” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, which changing the meaning of the description, so long as all occurrences of the “first contact” are renamed consistently and all occurrences of the second contact are renamed consistently. The first contact and the second contact are both contacts, but they are not the same contact.
The terminology used herein is for the purpose of describing particular implementations only and is not intended to be limiting of the claims. As used in the description of the implementations and the appended claims, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in accordance with a determination” or “in response to detecting,” that a stated condition precedent is true, depending on the context. Similarly, the phrase “if it is determined (that a stated condition precedent is true)” or “if (a stated condition precedent is true)” or “when (a stated condition precedent is true)” may be construed to mean “upon determining” or “in response to determining” or “in accordance with a determination” or “upon detecting” or “in response to detecting” that the stated condition precedent is true, depending on the context.
The foregoing description included example systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative implementations. For purposes of explanation, numerous specific details were set forth in order to provide an understanding of various implementations of the inventive subject matter. It will be evident, however, to those skilled in the art that implementations of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures and techniques have not been shown in detail.
The foregoing description, for purpose of explanation, has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The implementations were chosen and described in order to best explain the principles and their practical applications, to thereby enable others skilled in the art to best utilize the implementations and various implementations with various modifications as are suited to the particular use contemplated.
Patent | Priority | Assignee | Title |
10241835, | Feb 24 2014 | HUAWEI TECHNOLOGIES CO , LTD | Scheduling storage and computing resources based on task types and service levels |
10303513, | Mar 13 2013 | Microsoft Technology Licensing, LLC | Durable program execution |
11036551, | Mar 13 2013 | Microsoft Technology Licensing, LLC | Durable program execution |
9396030, | Mar 13 2013 | Samsung Electronics Co., Ltd. | Quota-based adaptive resource balancing in a scalable heap allocator for multithreaded applications |
9639399, | Feb 01 2013 | TENCENT TECHNOLOGY (SHENZHEN) COMPANY LIMITED | Method, apparatus and terminal for releasing memory |
Patent | Priority | Assignee | Title |
6408313, | Dec 16 1998 | Microsoft Technology Licensing, LLC | Dynamic memory allocation based on free memory size |
6539464, | Apr 08 2000 | Memory allocator for multithread environment | |
20070233991, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Apr 01 2013 | Google Inc. | (assignment on the face of the patent) | / | |||
Jul 31 2013 | KESSELMAN, ALEX | Google Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035873 | /0279 | |
Sep 29 2017 | Google Inc | GOOGLE LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 044334 | /0466 |
Date | Maintenance Fee Events |
Apr 08 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Apr 06 2023 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Date | Maintenance Schedule |
Oct 06 2018 | 4 years fee payment window open |
Apr 06 2019 | 6 months grace period start (w surcharge) |
Oct 06 2019 | patent expiry (for year 4) |
Oct 06 2021 | 2 years to revive unintentionally abandoned end. (for year 4) |
Oct 06 2022 | 8 years fee payment window open |
Apr 06 2023 | 6 months grace period start (w surcharge) |
Oct 06 2023 | patent expiry (for year 8) |
Oct 06 2025 | 2 years to revive unintentionally abandoned end. (for year 8) |
Oct 06 2026 | 12 years fee payment window open |
Apr 06 2027 | 6 months grace period start (w surcharge) |
Oct 06 2027 | patent expiry (for year 12) |
Oct 06 2029 | 2 years to revive unintentionally abandoned end. (for year 12) |