RU2460222C2 - System and method of allocating memory in embedded systems or wireless communication systems - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: first memory elements are allocated. Each of the memory elements contains a first heading and a payload, wherein the payload contains independently allocated memory areas, and the first heading contains a link to unallocated memory in the payload. Second memory elements are then allocated. Each of the second memory elements contains a second heading. The second heading contains a link to an allocated memory area in the payload of the first memory element. Memory allocation requests are received and responded to by returning a link from the heading of the first or second memory element.

EFFECT: reduced overall memory capacity required by different subsystems in a mobile device, and fewer processing resources consumed by a mobile device.

26 cl, 7 dwg

Description

This application claims the priority of provisional patent application US No. 61/041878, filed April 2, 2008

Technical field

The present invention generally relates to the field of memory allocation and, more particularly, to memory allocation in embedded or wireless communication systems.

State of the art

The memory allocation service uses storage pools. In some cases, memory elements are sorted into different pools based on the size of the memory element. For example, one pool may consist of many small memory elements, while another pool may consist of a relatively small number of large memory elements. In response to memory allocation requests, the corresponding data item may be selected from a particular pool and returned to the requesting entity. This system leads to a significant waste of memory and processor resources. For example, for small memory elements, the ratio of the header to the payload is high, resulting in inefficient use of memory. Additionally, when the elements of the entire memory are distributed, significant pieces of data of any particular data element may remain unused. In addition, no statistical multiplexing is available in these distribution services. Processor resources are also consumed due to the formation of chains of numerous small memory elements.

In wireless communication systems, packets are often segmented into small, fixed-size “radio link” packets, such as 40 bytes, to provide reliable radio transmission. To use memory efficiently, one approach is to create a large pool of relatively small memory elements, each of which stores a 40-byte block, which ultimately can chain at higher levels to form large data blocks (e.g. , 1500 byte IP packets). One of the drawbacks of such a service is that some space may be wasted, because the memory elements will have to be aligned on cache lines (32 or 64 bytes), which may not correspond to the small packet size of the radio link. In addition, different technologies can share the same pool of memory elements in order to reduce the total memory capacity, in which case the size of the payload of the memory element must be chosen to match the largest packet size of the radio link, which can further increase performance loss.

SUMMARY OF THE INVENTION

In one embodiment, a system is provided for providing memory management. The system includes a processor and a memory management service that runs on the processor. The memory management service is configured to create the first memory elements, each of the first memory elements containing a header and a payload, the payload configured to save a plurality of independently distributed memory sections, and the header of the first memory elements refers to the allocated space in the payload second memory elements, and each of the second memory elements contains a header that refers to one or more pieces of memory in Usable load first memory items, and return a reference from the header of any of the first or second memory item responsive to a memory allocation request.

In another embodiment, a memory management method is provided. The method comprises the steps of distributing the first memory elements, each of the first memory elements containing a first header and a payload, the payload containing sections of independently allocated memory, and the first header containing a reference to unallocated memory in the payload, distributing the second memory elements, moreover, each of the second memory elements contains a second header, and the second header contains a link to a distributed portion of memory in the payload of the first memory element They receive requests for memory allocation and respond to requests for memory allocation by returning a link from the header of the first or second memory element.

In another embodiment, a memory management system is provided. The system comprises means for distributing the first memory elements, each of the first memory elements containing a first header and a payload, the payload containing sections of independently allocated memory, and the first header containing a reference to unallocated memory in the payload, means for distributing the second memory elements, each the second memory element contains a second header, and the second header contains a link to a distributed portion of memory in the payload of the first element Yachi, means for receiving requests for memory allocation, and means for responding to requests for memory allocation by returning a reference from the header of a first or second memory item.

In another embodiment, a computer readable medium encoded by computer instructions is provided. The command, when executed, ensures that the processor performs the stages in which the first memory elements are allocated, each of the first memory elements containing the first header and the payload, the payload containing sections of the independently allocated memory, and the first header containing a reference to unallocated memory in the useful the load, distribute the second memory elements, and each second memory element contains a second header, and the second header contains a link to a distributed portion of The memories in the payload of the first memory element receive requests for memory allocation and respond to requests for memory allocation by returning a link from the header of the first or second memory element.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is further explained in the description of the preferred embodiments with reference to the accompanying drawings, in which:

figure 1 depicts a block diagram of an example of a mobile device;

figure 2 depicts a block diagram of an example of memory elements;

figure 3 depicts a block diagram of another example of memory elements;

4A and 4B are a flowchart of an example memory allocation method;

5 is a flowchart of various examples of a memory allocation service;

6 is a flowchart of another example of a memory allocation method.

DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE INVENTION

The following detailed description is directed to specific embodiments of the invention. The invention, however, can be practiced in many different ways. It should be obvious that the aspects set forth herein can be implemented in a wide variety of forms, and that any particular structure, function, or both, disclosed herein are merely exemplary embodiments. Based on the results presented herein, one of skill in the art should understand that any aspect disclosed herein may be practiced independently of any other aspects, and that two or more of these aspects may be combined in various ways. For example, a device may be implemented or a method may be implemented using any number of aspects set forth herein. In addition, such a device may be implemented or such a method may be implemented using a different structure, functionality, or structure and functionality in addition to one or more of the one aspects set forth herein.

Mobile devices typically use memory allocation services to operate. Methods and devices are described herein to reduce the total amount of memory required by various subsystems in a mobile device and to reduce the processing resources consumed by the mobile device. Below are some architectures that can be used in conjunction with the described methods and devices.

1 is a block diagram of an example of a mobile device 102. The device 102 includes a processor 202 that communicates with a storage device 204, and a network interface 206 for communicating via a wireless line 106. Alternatively, the device 102 may also include one or more devices 210, a user input device 212, such as a keyboard, touch screen, or other suitable tactile data input device, a speaker 214, comprising a transducer configured to provide acoustic an output, based on a signal received on the wireless line 106, and / or a microphone 216, comprising a transducer configured to provide an acoustic signal that can be transmitted on the wireless line 106. For example, a telephone may include a display device 210, configured to provide visual output for a graphical user interface (GUI).

Network interface 206 may include any suitable antenna (not shown), receiver 220, and transmitter 222 so that device 102, as an example, can communicate with one or more devices over a wireless line 106. Alternatively, network interface 206 can also have processing capabilities to reduce processing requirements for the processor 202.

Alternatively, device 102 may include a second network interface 208 that communicates over network 110 via line 108. For example, device 102 can communicate with another network 110 (eg, a wide area network such as the Internet) via wired or wireless communication line. Accordingly, device 102 may enable other devices 102 (eg, Wi-Fi stations) to access another network 110. In addition, it should be understood that one or more devices 102 may be portable or, in some cases, relatively non-portable. The second network interface 208 may transmit and receive radio frequency signals in accordance with the IEEE 802.11 standard, including IEEE 802.11 (a), (b) or (g), the BLUETOOTH standard and / or CDMA, GSM, AMPS, or other known signals, which are used for communication within a wireless cellular telephone network. In addition, the second network interface 208 may comprise any suitable wired network interface, such as Ethernet (IEEE 802.3), USB, or MDDI.

The device 102 may include a battery 231 for providing power to one or more components of the device 102. The device 102 may include at least one of a telephone, a smartphone, a personal digital assistant (PDA), an ultra-mobile personal computer (UMPC), a mobile Internet device (MID) or any other mobile device. In particular, the results contained herein can be used (for example, implemented within or implemented) in a variety of devices 102.

The components described herein can be implemented in various ways. With reference to FIG. 1, a device or equipment 102 is represented as a series of interacting functional blocks that can represent functions performed, for example, by processor 202, software, some combination thereof, or some other method, as described herein. For example, processor 202 may facilitate user input through data input devices 212. Additionally, the transmitter 222 may include a processor for transmitting, providing various functionalities related to transmitting information to another device 102. Receiver 220 may include a processor for receiving, which provides various functionalities related to receiving information from another device 102, as described herein .

The processor 202 also communicates with the memory allocation service 203. In one embodiment, the memory allocation service 203 runs on a processor 202. The memory allocation service 203 responds to memory requests from one or more subsystems operating in the device 102. The method and operation of the memory allocation service 203 will be described in more detail here below.

As noted above, FIG. 1 shows that in some aspects, these components can be implemented through respective processor components. These processor components may be implemented in some aspects using, at least in part, the structure described herein. In some aspects, the processor may be configured to implement part or all of the functionality of one or more of these components. In some aspects, one or more components represented by dashed rectangles are optional.

In one or more exemplary embodiments, the functions described may be performed by hardware, software, firmware, or any combination thereof. When implemented using software, the functions may be stored or transmitted by one or more instructions or code on a computer-readable storage medium. A computer-readable medium includes both a computer storage medium and a transmission medium including any transmission medium that facilitates transfer of a computer program from one place to another. Storage media can be any available media that can be accessed by a general purpose or specialized computer. By way of example, but not limitation, such computer-readable media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), a CD-ROM or other optical magnetic disk drive a disk drive or other magnetic storage devices or any other medium that can be used to transfer or store the desired means of control programs in the form of instructions or data structures, which can be accessed by a general purpose or special purpose computer or a purpose or special purpose processor. In addition, any connection is duly referred to as a computer-readable medium. For example, if software is being transferred from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair cable, digital subscriber line (DSL), or wireless technologies such as infrared, radio waves, and microwave, then the coaxial cable , fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio waves, and microwave are contained in the definition of the medium. The magnetic and non-magnetic discs used here include a compact disc (CD), a laser disc, an optical disc, a digital versatile disc (DVD), a floppy disk and a Blu-ray disc, where magnetic discs usually reproduce data in a magnetic manner, then how non-magnetic disks reproduce data optically with lasers. Combinations of the above discs should also be among the computer-readable media.

In accordance with one aspect of a memory allocation service, small memory blocks are packaged in large fixed-size blocks (called "DSM elements"). For each of the small blocks, tracking of the use of "DUP" elements (duplicate) is supported, which shows the payload inside the DSM. Since DSM elements are limited in size and all blocks within DSM can be assumed to have approximately the same limited life, there is no need to fragment free memory within each DSM. The advantage of this is that memory usage can be significantly reduced, since only a small fraction of the memory inside the DSM is wasted, but with some complexity, other memory allocation methods with high packing efficiency. Another way of presenting is that it is a hybrid of fixed-size and flexible-sized distribution services where shared memory is allocated to fixed-size blocks, but flexible-sized allocations are allowed within the blocks, because flexible allocations are expected to have a short term service.

In one aspect, the main memory unit is called a DSM element. It contains a header section and a payload section. When a data block is to be stored in memory, a new DSM element is allocated and the data is copied to the DSM payload section. Additionally, headers are updated to reflect the start and length of the data. If the data length exceeds the size of the payload partition, multiple DSM elements can be chained together in a linked list.

Additionally, a special type of DSM element is identified, designated as DUP ("duplicate"). DUP uses the same header structure as regular DSM, but it does not have its own payload partition. Instead, it can point to a data section elsewhere, for example, inside a regular DSM. To track how many DUPs point to data in the same DSM element, there is a header field labeled "ref_count" that counts the number of references to that DSM element, and which sets the unit when the initial DSM is allocated for the first time. Each time a new DUP is created, this is indicated inside the DSM element and the value of "ref_count" is incremented. Similarly, when the DUP is freed, the "ref count" of the original DSM is reduced. In this way, the distribution algorithm can know when the DSM element can be virtually free, which happens only when no other DUPs point to the payload section of this packet, which happens when the value of "ref_count" returns to zero.

DUPs can be used to break packages, reorganize data, delete headers, etc., without having to affect the original data. All of this can be achieved simply by manipulating the DSM and DUP headers.

In another aspect, methods for packing data into the same DSM to improve memory performance may address some of the drawbacks noted previously. In accordance with this aspect, a large DSM element pool is defined. The large DSM size should allow the data of multiple radio link packets to be combined into the same DSM element.

2 is a block diagram showing memory elements of a memory allocation service. The memory allocation service may include an application program interface (“API”). This API may be accessible to subsystems, such as the subsystems present in the API device 102. This memory allocation service may be performed in whole or in part by processor 202 or other similar processing device. Additionally, the API may form part of the operating system for a mobile or wireless device, such as device 102. Alternatively, the API may form part of a software library. 2 shows a first type of memory element 610. This first type of memory element 610 may be referred to as a data transfer control ("DSM"). Alternatively, it may be referred to as a container element. These container-type memory elements 610 are organized as a pool of memory elements 605. Although a single pool 605 is shown in the figure, it should be understood that multiple DSM element pools may also be used. Each pool can be characterized by one or more common characteristics, such as the size of the element or subsystem serviced by the pool.

Figure 2 also presents an enlarged view of the element 610 memory. As seen in an enlarged view, these container-type elements 610 contain numerous sections. The first section of the memory element may be referred to as the header 615. The header 615 may contain information related to the remaining parts of the memory element 610, as well as other information. The second section of memory element 610 may be referred to as a payload. The payload itself may have several distributed parts or memory blocks 620. In addition, the payload may have unallocated or unused space 625. In one embodiment, the payload contains approximately 1,500 bytes, a size approximately necessary to store an IP packet.

The header 615 of the memory element 610 may contain information such as a reference to the unallocated space 625 in the memory element 610. In one example, this link takes the form of a pointer indicating the starting address of the unallocated space 625 in memory element 610. This reference to unallocated memory 625 in data element 610 may also be referred to as "data_ptr". The header may also contain a field indicating the size of the distributed memory 620. This amount of distributed space may be referred to as “used” space in the payload. The header may also contain a field indicating an identifier that identifies the memory pool 605 associated with the memory element 610. This identifier may be referred to as "pool_id". The header may also contain a field indicating the number of links to memory element 610. For example, as described below, other memory elements may refer to memory element 610. For example, a different memory element refers to each of the distributed sections 610 of the payload memory. Additionally, the header 615 of the memory element 610 refers to the unallocated portion 625 of the payload. The count of these links can be used, inter alia, for the purpose of determining when the memory element 610 can be freed and returned to the pool 605 to be subsequently redistributed. This reference count may be referred to as “links”. Header 615 may also contain one or more references to other memory elements. For example, if the requested memory location is too large to correspond to a single memory element 610, links in the header can be used to indicate one or more additional memory elements that can be chained together to satisfy the request. Depending on the type of referenced memory items, these links may be referred to as "pkt_ptr" or "dup_ptr". For example, pkt_ptr may refer to zero or more DSM elements or container elements, while dup_ptr may refer to zero or more DUP elements. In addition to the identified fields, header 615 may include additional fields, such as a user-defined field or fields used for testing purposes. In addition, header 615 may skip one or more identified fields.

2 also shows a second type of memory element 630. This second type of memory element may be referred to as a duplicate or “DUP” memory element. These DUP elements 630 contain a header similar to the header 615 of the container memory elements 610. For example, DUP elements may have the same fields as the title of the 615 DSM element. Alternatively, DUP elements may have more or less fields. However, these DUP elements do not have their own payload. Rather, the headers 630 of the DUP elements contain references to container memory elements. In one specific example, the DUP element 630 comprises a pointer indicating a first memory allocation unit in the distributed portion 620 of the memory element 610. These DUP elements 630 may also be implemented in one or more pools 640. Like multiple pools of container elements 605, multiple DUP element pools may be used. For example, FIG. 2 shows two pools 640 and 650 of DUP elements. In one example, each subsystem in an embedded device or in a wireless device has its own DUP element pool. In this embodiment, pool 640 may correspond to one particular subsystem, while pool 650 may correspond to another subsystem. As can be seen in FIG. 2, one embodiment ensures that DUP elements from individual pools can refer to memory units 620 in a single DSM element 610.

Figure 3 shows an alternative embodiment of the memory elements shown in figure 2. As before, a single pool of 715 DSM elements can be used. However, this time, each pool of DUP elements 730 and 735, respectively, refers to the distributed parts of different DSM elements 725 and 720. As described above, DSM elements can be returned to the DSM pool 715 for redistribution as soon as all links in the payload are released. However, when multiple subsystems are allowed to have DUP links in the same DSM element, fragmentation can occur. For example, all the memory allocated to the first subsystem in a particular DSM could already be freed. However, if a small block is still referenced by a DUP from another subsystem, the remaining memory in the payload may wait until it is freed until the second subsystem releases its small memory block. To minimize this problem, each subsystem can have its own DUP links in its own DMS. In this way, the lifetimes of the distributed parts of the memory in a particular DSM are likely to be the same. The similarity of service life will lead to a decrease in fragmentation.

4A and 4B show an embodiment of a method 780 for allocating memory. This method 780 can be performed as a service running on a processor, such as processor 202. Method 780 facilitates receiving memory allocation requests and returning references to distributed memory. As described below, a specific assigned link may be a function of the current memory allocation situation to query the subsystem and the size of the requested memory block. Additionally, it should be noted that some of the steps may be omitted to satisfy the requirements or special requirements of a particular application. Additionally, it should be noted that some of the steps described here are optimizations and, thus, can be selectively used or omitted at the discretion of the system developer.

Method 780 begins when the memory allocation service in step 785 receives a memory request. As part of a memory request, the requesting subsystem may indicate the requested memory size. The requesting subsystem may also provide a subsystem identifier so that the memory allocation service can select the appropriate DSM element for that subsystem. After receiving the memory request, the memory allocation service determines whether the requested size is less than the size of the unallocated memory in the current DSM container element, as shown in decision block 790. As discussed with reference to FIGS. 2 and 3, DSM elements may have unallocated space in the payload section. Step 790 decision can be performed by comparing the size of the unallocated part with the requested size. Alternatively, since the total payload size is known, the requested volume can be compared with the size of the distributed portion of the payload. In another embodiment, instead of using the requested memory size for comparison, the memory allocation system may increase the size of the request so that the enlarged request is aligned with the cache boundaries. For example, the actual request may be increased so that the resulting request is a multiple of a particular cache line size, such as 16, 32, 64, or 128 bytes. Regardless, if the requested memory size or its enlarged aligned version fits into the unallocated part, the method proceeds to step 800.

At decision block 800, the memory allocation system determines whether the requested size plus the size of the previously allocated portion of the current DSM is larger than the first threshold. For example, if the DSM payload is approximately 1,500 bytes in length, the threshold may be 1,200 bytes. Accordingly, the memory allocation system must determine whether the size of the memory already allocated plus the size of the requested memory exceeds the 1200-byte limit. In one embodiment, the threshold may be selected as a certain percentage of the payload size of the DSM element. For example, the threshold may be approximately 70% -80% of the size of the payload. In another embodiment, a threshold size may be selected to reflect general request size characteristics, such as memory requests for storing IP packets. In another embodiment, instead of comparing the size of the distributed memory with a threshold, the size of the remaining unallocated memory can be compared with the threshold. In this embodiment, the service must calculate the portion of the payload that may remain unallocated if the requested or adjusted memory size has been allocated. Comparison of the remaining unallocated memory with this threshold can then be used in a manner similar to the previously discussed comparison of distributed memory with a threshold.

In decision block 800, if the identified amount is greater than the threshold, the method proceeds to block 805. When proceeding to block 805, the memory allocation system returns a link to the requesting subsystem. In one embodiment, the returned link is data_ptr from the header of the current DSM element. Preferably, by returning the link from the DSM element header, the memory allocation system stores the overhead and resources involved in creating the DUP element and returning the link from the DUP header. Additionally, the distribution of the remainder of the DSM payload, not just the requested size, allows the memory allocation service to avoid small blocks of data at the end of the payloads, which, if not, could lead to chaining.

Returning to decision block 800 if the requested memory size plus the already allocated memory size is not more than a threshold, the method proceeds to block 810. At block 810, the memory allocation service creates a DUP element, allocates the requested memory and returns a link in the DUP to the requesting subsystem. Preferably, through multiple iterations, this method allows the memory allocation service to pack multiple allocations into a single DSM element. This packaging allows efficient use of memory resources and provides a gain in both memory usage and processing utilization.

Returning to step 790, if the requested memory size is larger than the unallocated space in the current DSM, the method proceeds to decision block 845 in FIG. 4B. At decision block 845, the memory allocation service determines whether the requested size exceeds the second threshold. This second threshold, like the first, can be set as a fixed number of bytes. For example, if the payload size of a DSM element is 1600 bytes, the second threshold may be 1200 bytes. Alternatively, a second threshold may also be defined as a percentage of the size of the payload. For example, the second threshold may be 65% -75% of the size of the payload. In another embodiment, the threshold may be determined dynamically. For example, the threshold may be set equal to the total amount of distributed memory in the DSM element. In this embodiment, the requested size may exceed a threshold when the requested size exceeds the allocated space in the DSM. Regardless of how the threshold is determined, if the requested size is larger than this threshold, the memory allocation service allocates a new DSM element and returns data_ptr from the new DSM element header to the requesting subsystem, as shown in block 850. Like in block 805, this process returns a link from The header of the new DSM element saves overhead for creating a new DUP element. The requesting subsystem is given more than what it asked for, the whole DSM element, and this allocation allows the subsequent allocation requests to be satisfied with the unallocated memory remaining in the current DSM element.

Returning to step 845, if the requested size is less than this second threshold, the method proceeds to step 855. At step 855, the DSM element header link is removed to the unallocated portion of the DSM payload. This actually frees up the rest of the DSM element. In addition, a new DSM item is created. The memory block is allocated in the new DSM element, and the corresponding DUP is created. The link in the new DUP to the new DSM is then returned to the requesting subsystem.

For the purpose of explanation, FIG. 5 shows examples of the above method. In case 1, the current DSM element 910 is shown. The current DSM has both distributed part 915 and unallocated part 920. The requested packet size 925 is shown as the first threshold 930. As can be seen in the figure, the size of the distributed part 915 plus the size of the requested part 925 is smaller than the first threshold 930. Accordingly, as shown, the element portion 935 DSM is distributed and a new DUP is created, and its link is returned to the requesting subsystem. The new DUP element includes a link to the DSM 935, which indicates the start of newly distributed data.

In case 2, the current DSM 955 is shown together with another requested packet 960. As shown in the figure, the size of the distributed portion of the DSM 955 plus the size of the requested packet exceeds the first threshold, but the sum does not exceed the total payload length. Accordingly, a reference to the unallocated portion of the DSM element 965 is returned to the requesting subsystem. The result is that in addition to obtaining the requested memory size or even a slightly larger adjusted row allocation, the requesting subsystem will receive all the remaining unallocated space 980 in the DSM 965. Again, returning the link from the DSM element header saves the service command to create the DUP and eliminates the formation chains potentially formed by stub 980, which otherwise could have been left.

In case 3, the current DSM 985 is shown with another requested memory unit 990. As shown in the figure, the requested packet is too large to fit in the unallocated portion of the current DSM. In addition, the requested size is smaller than the second threshold 995. Accordingly, the link in the header of the current DSM 1000 to unallocated parts of the payload is deleted. A new DSM 1005 is created. The memory block from this DSM is allocated, and a new DUP element is created that refers to the distributed block in the new DSM. The link from this new DUP element is then returned to the requesting subsystem. Again, it should be understood that although the second threshold 995 is shown as static, the threshold can be determined dynamically, for example, setting it equal to the size of the distributed memory in the original.

In case 4, the DSM 1010 is shown along with the requested memory unit 1015. As in case 3, the requested size is too large to fit in the unallocated portion of the DSM element 1010. In addition, the requested block size 1015 is larger than the second threshold 995. As a result, the current DSM 1020 is stored in its current state. Meanwhile, a new DSM 1025 is created, and the link to the unallocated portion of the payload in the new DSM header is returned.

The method shown in FIG. 6 is similar to the method shown in FIGS. 4A and 4B. However, FIG. 6 proposes changes with respect to certain parameters used in an embodiment of a service for allocating memory. The method 1080 shown in FIG. 6 provides an API for memory allocation requests. In one particular embodiment, method 1080 provides a function request for subsystems that can be used to request memory allocation. As shown in the figure, the function may take as a parameter the requested size of the memory allocation. In addition, the function may take other parameters, such as a subsystem identifier that identifies the requesting subsystem. The service presented in accordance with FIG. 6 can be configured to be executed on a processor, such as processor 202 of device 102. In response to distribution requests, the service, as discussed below, prepares a pointer to a distributed memory block with a size greater than or equal to requested size. Accordingly, subsystems that use the service API return a pointer to distributed memory. In one specific embodiment, the method shown in FIG. 6 uses some or all of the following values during its operation:

current_dsm_item_ptr []: this is a set of pointers to the current DSM element for each subsystem.

aligned_pkt_size: this is the size of the requested memory block, adjusted to be aligned with cache lines of sizes such as 16, 32, 64, or 128.

pkt_ptr: pointer to the distributed memory that is about to be returned.

DSMI_MEM_THRESHOLD_TO_FREE_DSM: The first threshold to determine if a DUP or DSM link should be returned. If, after allocating the memory block, the remaining unallocated memory should be less than this threshold, the DSM link is returned, effectively allocating all the remaining unallocated memory in the DSM element.

DSMI_THRESHOLD_FOR_COMPLETE_ITEM_ALLOCATION: second threshold for determining whether DUP or DSM links should be returned. If the requested packet size is greater than this threshold, a new DSM is created and a link is returned from the header of the new DSM. The current DSM is saved.

The method shown in FIG. 6 starts with a function request shown in step 1085. As a request parameter, the distribution service accepts the requested packet size “pkt_size”. In addition, in some embodiments, another parameter, a subsystem identifier, must also be passed in the function request. Going to step 1100, the method blocks a specific pool of DSM elements to avoid concurrent access problems. After the pool is locked, the method proceeds to decision block 1105. At decision block 1105, the service determines whether pkt_ptr is null. If no memory was allocated on request, the pointer may be null. However, if the pointer has a non-zero value, the service proceeds to unlock the pool at step 1140 and returns the pointer to step 1145. However, if the pointer is zero, the service proceeds to decision block 1110.

Continuing to decision block 1110, the service determines whether current_dsm_item_ptr is zero. If the previous iterations did not result in any current existing DSM element, at 1115 the service proceeds to create it and stops creating it if it fails at 1120, 1140, 1145. As soon as the existence or creation is confirmed for the actual current DSM , the method proceeds to decision block 1125. At decision block 1125, the service determines whether the aligned requested size is less than the unallocated space size in the current DSM. If so, at 1130, the service then determines whether the unallocated space that should remain after allocating the requested memory in the DSM is smaller than the first threshold. If so, the service creates a DUP in step 1135 and allocates the aligned requested memory in the current DSM, unlocks the pool in step 1140, and returns the DUP pointer in step 1145. Otherwise, the service creates a completely new DSM in step 1150, unlocks the pool in step 1140, and at 1145, returns a pointer from the header of the new DSM.

Returning to step 1125, if the requested size is larger than the remaining unallocated space, the method proceeds to decision block 1155. At step 1155, the service determines whether the requested size of the second threshold is greater than or equal to it. If so, the service creates an entirely new DSM 1165, unlocks pool 1140, and returns the pointer from the header of the new DSM 1145. Otherwise, the service frees up the remaining memory in the current DSM and proceeds to run the method again at step 1105. The result is that created a new DSM and a DUP is created that references the body of the new DSM, and the DUP pointer is returned to the requesting subsystem.

Additional features and embodiments of the present memory allocation service are also provided.

Numerous DSM Pointers for Various Users

For use in cases in which the service life of the blocks is expected to be significantly different for different users, the algorithm can support multiple DSM pointers and pack data blocks with similar lifetimes in the same DSM. For example, a specific user identifier may be transmitted along with a distribution request, so that only data from that user will be packaged in the same DSM element. Requests from other users must be packaged in other DSMs. Here, the “user” can be a set of tasks or subtasks, or levels, or functions, or any other combination of them, to distinguish one set of user profile from another.

Support for adding data in front (or back) of DSM

To effectively add data in front of an existing DSM or DUP element (that is, add protocol headers) without distributing a new DSM element and performing chaining, it is proposed to provide DSM distribution with free space in front. Free space is supported by tracking using the "offset" header. In this way, a DUP or DSM can be distributed at a given offset and later, if more data needs to be inserted before the DSM, this can be done without a new DSM distribution, followed by chaining. A similar service may be provided to add data at the end of the DSM.

Numerous pools

The service allows multiple DSM pools to reserve a given number of items to a specific user. This is the way in which the user does not have to worry that suddenly there will be no free DSM elements anymore, because all of them were distributed by another user. In addition, this provides better debugging capabilities for memory overflow problems (when one user does not take into account the distribution boundaries), because the problem is limited only by the size of the user's code alphabet.

Quota service as an alternative to multiple pools

Another way to achieve the same is to have one pool, but each user has a maximum quota of DSM elements (bytes) that he can allocate. Once it has reached its quota, it must free some items in order to distribute new items in order to avoid the lack of memory for other users. One of the advantages this approach has over the multiple pool approach is that sharing can be achieved. For example, if there are 4 users with their own pool of X elements, this would require 4X memory elements. However, since it is very unlikely that all 4 users will distribute all the items at the same time, the quota service may allow reducing the total memory, say, to 3X, assuming that if one user takes all his memory equal to X, the remaining 3 users will be able to share the remaining memory equal to 2X.

Numerous DSM pointers for various sizes

In this aspect, the DSM distribution may be partitioned based on the requested memory space (as opposed to using the subsystem identifier described above). Instead of using the traditional pool path of multiple sizes, shared across multiple levels / subsystems to meet the needs of all tasks / profiles, this proposal can provide support for multiple DSM pointers, of which only blocks of a certain size can be allocated for each DSM pointer. For example, we can have a DSM pointer for block sizes of 128, 256, 512, 768, 1024, 1536 bytes, and so on.

Whenever any level / module requests for a specific memory size, the algorithm can determine the most suitable DSM pointer and provide a duplicate if the requested size is available. If the requested size is not available, then release the DSM pointer (if it is not null) for that size and allocate a large element from the global pool of large elements (for example, elements larger than a given number of bytes, in one example, elements greater than or equal to 768 bytes ), and then the DUP will best fit the block size and return the DUP to the caller.

The present distribution also has several distinctive advantages over the prior art. Embodiments of the present service reduce memory footprint. Using fewer pools provides better statistical multiplexing. The service provides the best packaging efficiency. DSM elements require less utility commands, even when adding utility commands for DUP. Service Processor Central Processing Unit (MIPS) is reduced due to fewer chains. The service permits the use of large DSM elements, avoiding long chains in a packet (especially with large packet sizes), thereby reducing the number of DSM distribution / release operations. Embodiments simplify maintenance associated with a more traditional approach involving multiple memory pools. The service can be implemented as having a central API for processing, and this helps to avoid the need to implement such functionality in each subsystem, thereby duplicating the code. The need for separate pool sizes and element sizes for each target value is eliminated. Without the methods described here, it would be necessary to execute the code separately in many places (for example, various or multiple levels on the stack, such as the packet service module (PS), high-speed USB module (HS-USB), etc.), which are more prone to errors, etc. It is possible to define a DUP pool in high-speed memory to further improve performance (for example, cache benefits), for example by defining a DUP pool in low-latency memory (for example, internal random access memory (IRAM)). Reduced checks in DSM can be obtained if only one pool is used with this application programming interface (API). DSM currently performs some checks based on the pool identifier (identification), which is passed as a parameter.

Claims (26)

1. A memory management system comprising:
processor and
a memory management service running on the processor, the memory management service configured to:
creating the first memory elements, each of the first memory elements containing a header and a payload, with the payload configured to store a plurality of independently distributed portions of memory, and the header of the first memory elements refers to the allocated space in the payload;
creating second memory elements, each of the second memory elements containing a header that refers to one or more sections of memory in the payload of the first memory elements; and
returning a link from any header of the first or second memory element sensitive to the memory allocation request. 2. The memory management system according to claim 1, in which the header of the first memory elements keeps track of links to the first memory elements. 3. The memory management system according to claim 1, wherein the memory management service is further configured to create separate first memory elements for each of the plurality of subsystems. 4. The memory management system according to claim 1, in which the memory allocation request contains the requested memory size. 5. The memory management system according to claim 4, in which the memory management service is further configured to determine the sum of the size of the distributed memory in the payload of a particular first memory element and the requested memory size and comparing the amount with a threshold value. 6. The memory management system according to claim 5, in which the memory management service is further configured to create and return links from the header of a specific second memory element when the sum is less than a threshold value. 7. The memory management system according to claim 6, in which the memory management service is further configured to return a link from the header of a particular first memory element when the sum is greater than a threshold value. 8. The memory management system according to claim 4, in which the memory management service is further configured to determine the sum of the size of the distributed memory in the payload of a particular first memory element and the requested memory size, comparing the amount with the payload size of a specific first memory element and comparing the requested size memory with a threshold value. 9. The memory management system of claim 8, in which the memory management service is further configured to create another specific first memory element, create a specific second memory element that refers to the payload of another specific first memory element and return a link from the header of a specific second memory element when the sum is greater than the payload size of the particular first memory element, and the requested memory size is less than the threshold value. 10. The memory management system of claim 8, in which the memory management service is further configured to create another specific first memory element and return a link from the header of another specific first memory element, when the sum is larger than the payload size of the specific first memory element, and the requested size memory is greater than the threshold value. 11. The memory management system of claim 8, in which the threshold value is the size of the distributed memory in a particular first memory element. 12. The memory management system according to claim 4, in which the memory management service is further configured to increase the requested memory size to align the requested memory size with the cache line boundary. 13. A method of managing memory, comprising stages in which:
distributing the first memory elements, each of the first memory elements containing a first header and a payload, the payload containing sections of independently allocated memory, and the first header containing a reference to unallocated memory in the payload;
distributing the second memory elements, with each of the second memory elements containing a second header, the second header containing a link to a distributed portion of memory in the payload of the first memory element;
accept requests for memory allocation; and
respond to memory allocation requests by returning a link from the header of the first or second memory element. 14. The method according to item 13, in which the first header further comprises a reference count in the first memory elements. 15. The method according to item 13, in which the distribution of the first memory elements further comprises the distribution of the individual first memory elements for each of the many subsystems. 16. The method of claim 13, wherein the memory allocation request comprises a requested memory size. 17. The method according to clause 16, in which additionally determine the sum of the size of the distributed memory in the payload of a particular first memory element and the requested memory size and compare the sum with a threshold value. 18. The method according to 17, in which additionally distribute and return links from the header of a specific second memory element when the sum is less than a threshold value. 19. The method according to p, in which additionally return links from the header of a particular first memory element when the sum is greater than a threshold value. 20. The method according to clause 16, further comprising stages in which:
determining the sum of the size of the distributed memory in the payload of the particular first memory element and the requested memory size;
comparing the sum with the payload size of the particular first memory element and
compare the requested memory size with a threshold. 21. The method according to claim 20, further comprising stages in which:
create another private first memory element;
create a private second memory element that refers to the payload of another private first memory element; and
return a link from the header of the private second memory element when the sum is greater than the payload size of the private first memory element and the requested memory size is less than the threshold. 22. The method according to claim 20, further comprising stages in which:
create another private first memory element; and
return a link from the header of another private first memory element when the sum of the payload size of the private first memory element and the requested memory size is greater than the threshold. 23. The method according to claim 20, in which the threshold is equal to the size of the distributed memory in the private first memory element. 24. The method according to clause 16, in which the requested memory size is further increased to align the requested memory size with the cache line boundary. 25. A memory management system comprising:
means for distributing the first memory elements, each of the first memory elements containing a first header and a payload, wherein the payload contains sections of independently allocated memory, and the first header contains a reference to unallocated memory in the payload;
means for distributing the second memory elements, each of the second memory elements containing a second header, the second header containing a link to a distributed portion of memory in the payload of the first memory element;
means for receiving memory allocation requests; and
query response means for allocating memory by returning a link from the header of the first or second memory element. 26. A computer-readable storage medium encoded by computer instructions that, when executed, ensure that the processor performs the steps in which:
distributing the first memory elements, each of the first memory elements containing a first header and a payload, the payload containing sections of independently allocated memory, and the first header containing a reference to unallocated memory in the payload;
distributing the second memory elements, with each of the second memory elements containing a second header, the second header containing a link to a distributed portion of memory in the payload of the first memory element;
accept requests for memory allocation and
respond to memory allocation requests by returning a link from the header of the first or second memory element.

Images