Memory management method for multi-core system and multi-core system, device, and medium

By introducing a memory management priority mechanism in a multi-core system, the memory management priority is dynamically adjusted, and the problem of unbalanced allocation of public system memory resources in a multi-core system is solved, and the system memory utilization and operation efficiency are improved.

CN119201482BActive Publication Date: 2025-02-18ARTMEM TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411731518.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-11-29
Publication Date
2025-02-18
Estimated Expiration
2044-11-29

AI Technical Summary

Technical Problem

In multi-core systems, when unbalanced allocation of memory resources in public systems leads to memory tightness, the system's operating efficiency is reduced, which may cause deadlocks or abnormal operation.

Method used

By introducing a memory management priority mechanism in a multi-core system, the initial memory management priority of the master and slave core units are identified as the second level, and the memory management priority is dynamically adjusted according to the system operation to achieve reasonable memory allocation.

Benefits of technology

Improve system memory utilization, ensure that multi-core systems can run efficiently and correctly when memory is tight, and reduce the occurrence of operational exceptions and deadlocks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119201482B_ABST
    Figure CN119201482B_ABST
Patent Text Reader

Abstract

The present application discloses a memory management method for a multi-core system and a multi-core system, device, and medium, and relates to the field of memory management technology. The method includes: the main core unit identifies the initial memory management priority of the main core unit and each slave core unit as the second level; the memory management priority also includes: the first level higher than the second level and the third level lower than the second level; judging the system operation status; updating and determining the current memory management priority of the main core unit and each slave core unit according to the system operation status and the second level; the memory manager performs memory scheduling and allocation processing according to the memory scheduling allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates idle memory units to the applicant so that the applicant can execute tasks in the task queue; the applicant is the main core unit or the slave core unit. It can improve the system memory utilization and ensure that the multi-core system runs efficiently and correctly.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of memory management technology, and in particular to a memory management method for a multi-core system, and a multi-core system, device, and medium. Background Art

[0002] In a multi-core or multi-tasking system architecture, there is usually a large common system memory resource for storing a large amount of interactive data. There is also a memory management mechanism in the multi-core operating system, which is responsible for the application and release of common system memory resources. All cores share this block of system memory resources. However, the programs of each core run independently of each other. When a core needs to process a large amount of data, it may occupy all the common system memory, making it unusable for other cores. If there is an operation dependency between multiple cores, it may cause system operation abnormality or deadlock.

[0003] In the related art, the public system memory is divided into multiple memory partitions, and each core is allocated a small private memory partition. Then multiple cores share the remaining larger public memory partition, so that no core can occupy all the memory. When the memory is tight, it can still apply for memory use. When this method cannot fully utilize the public system memory, and when the memory is tight, the system operation efficiency will also be reduced due to the small private memory partition of each core. Summary of the invention

[0004] The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes a memory management method for a multi-core system, a multi-core system, an electronic device, and a storage medium, which can improve the system memory utilization and ensure that the multi-core system runs efficiently and correctly.

[0005] In a first aspect, an embodiment of the present application provides a memory management method for a multi-core system, which is applied to a multi-core system, wherein the multi-core system includes: a memory manager, a plurality of common equally divided memory units, a master core unit, and at least one slave core unit; the method includes:

[0006] The master core unit marks the initial memory management priorities of the master core unit and each of the slave core units as the second level; the memory management priority also includes: a first level higher than the second level and a third level lower than the second level;

[0007] Determine the system operation status; update and determine the current memory management priority of the master core unit and each of the slave core units according to the system operation status and the second level;

[0008] The memory manager performs memory scheduling and allocation processing according to the memory scheduling and allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates the idle memory unit to the applicant so that the applicant can execute the task in the task queue; the applicant is a master core unit or a slave core unit;

[0009] Among them, the updating and determining of the current memory management priority of the main core unit and each of the slave core units according to the system operation status and the second level includes: when the system operation status is: memory resources are tight and the main core task executed by the main core unit is urgent, determining that the current memory management priority of the main core unit is increased from the second level to the first level, and determining that the memory management priority of the slave core unit is reduced from the second level to the third level.

[0010] In a second aspect, an embodiment of the present application provides a multi-core system, comprising: a memory manager, a plurality of common equally divided memory units, a master core unit and at least one slave core unit; the memory manager, the master core unit and the slave core unit cooperate with each other to execute the memory management method for the multi-core system as described in any one of the embodiments of the first aspect.

[0011] In a third aspect, an embodiment of the present application provides an electronic device comprising at least one processor and a memory for communicating with the at least one processor; the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the memory management method for a multi-core system as described in any one of the embodiments of the first aspect.

[0012] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the memory management method for a multi-core system as described in any one of the embodiments of the first aspect.

[0013] The embodiment of the present application includes: when the multi-core system is running, first, the main core unit identifies the initial memory management priority of the main core unit and each slave core unit as the second level; the memory management priority also includes: the first level higher than the second level, and the third level lower than the second level; then, the system operation status is judged; then, according to the system operation status and the second level, the current memory management priority of the main core unit and each slave core unit is updated and determined; a reliable reference is provided for the subsequent memory manager to perform memory scheduling and allocation, so as to achieve reasonable allocation of memory to improve the system memory utilization; finally, the memory manager performs memory scheduling and allocation processing according to the memory scheduling and allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates idle memory units to the applicant so that the applicant can execute the task in the task queue; the applicant is the main core unit or the slave core unit; so as to ensure that the multi-core system can run efficiently and correctly. That is to say, the embodiment of the present application can improve the system memory utilization and ensure that the multi-core system runs efficiently and correctly. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a schematic diagram of a system architecture for executing a memory management method for a multi-core system provided by an embodiment of the present application;

[0015] Figure 2 It is a flowchart of a memory management method for a multi-core system provided by an embodiment of the present application;

[0016] Figure 3 This is a schematic diagram of a specific process of a memory manager applying for memory provided by an embodiment of the present application;

[0017] Figure 4 It is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0019] It should be understood that in the description of the present application, the orientation descriptions, such as up, down, front, back, left, right, etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.

[0020] It should be noted that although a logical order is shown in the flowchart in the description of the present application, in some cases, the steps shown or described may be performed in an order different from that in the flowchart. In the description of the present application, a number of means one or more, and a plurality of means two or more. The description of "first" and "second" is only used for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0022] The present application discloses a memory management method for a multi-core system, a multi-core system, an electronic device and a computer-readable storage medium, and relates to the field of memory management technology. The method includes: the main core unit identifies the initial memory management priority of the main core unit and each slave core unit as the second level; the memory management priority also includes: the first level higher than the second level and the third level lower than the second level; judging the system operation status; updating and determining the current memory management priority of the main core unit and each slave core unit according to the system operation status and the second level; the memory manager performs memory scheduling and allocation processing according to the memory scheduling allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates idle memory units to the applicant so that the applicant can execute tasks in the task queue; the applicant is the main core unit or the slave core unit. It can improve the system memory utilization and ensure that the multi-core system runs efficiently and correctly.

[0023] The embodiments of the present application are further described below in conjunction with the accompanying drawings.

[0024] like Figure 1 As shown, Figure 1 This is a schematic diagram of the system architecture of a multi-core system provided by an embodiment of the present application; the multi-core system includes: a memory manager, a plurality of public equally divided memory units, a master core unit and at least one slave core unit.

[0025] It should be noted that the memory manager is electrically connected to the memory unit, the master core unit, and the slave core unit respectively, the master core unit is electrically connected to the slave core unit, and the slave core units are electrically connected to each other.

[0026] It can be understood that the multiple public equally divided memory units are obtained by dividing the public memory in the multi-core system. The memory units are used to store a large amount of interactive data to facilitate the main core unit and the slave core unit to perform tasks.

[0027] It can be understood that the main core unit is used to: mark the initial memory management priority of the main core unit and each slave core unit as the second level; wherein the memory management priority also includes: a first level higher than the second level and a third level lower than the second level; that is, the first level is higher than the second level, and the second level is higher than the third level; judge the system operation status; update and determine the current memory management priority of the main core unit and each slave core unit according to the system operation status and the second level; provide a reliable reference for the subsequent memory manager to perform memory scheduling and allocation, thereby realizing reasonable allocation of memory to improve system memory utilization.

[0028] The memory manager is used to perform memory scheduling and allocation processing based on the memory scheduling and allocation request sent by the applicant, the system operation status, the type of the applicant, and the applicant's current memory management priority, and allocate free memory units to the applicant so that the applicant can execute tasks in the task queue; the applicant is a master core unit or a slave core unit; thereby ensuring that the multi-core system can run efficiently and correctly.

[0029] The disadvantage of the prior art is that it cannot fully utilize the public memory, and when the memory resources are tight, the small private memory partition of each core causes troubles in program processing. Based on this, the multi-core system provided by the embodiment of the present application can realize the memory management mechanism of the multi-core system based on the mutual cooperation between the memory manager, the master core unit, and the slave core unit; thereby improving the system memory utilization and ensuring the efficient and correct operation of the multi-core system.

[0030] Those skilled in the art will appreciate that the system structure shown in the figure does not constitute a limitation on the embodiments of the present application, and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0031] The system embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment.

[0032] Those skilled in the art will appreciate that the system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0033] Based on the above system structure, various embodiments of the memory management method for a multi-core system of the present application are proposed below.

[0034] First, as Figure 2 As shown, the memory management method for multi-core systems can be applied to Figure 1 In the multi-core system shown, the multi-core system includes: a memory manager, a plurality of common equally divided memory units, a master core unit and at least one slave core unit; the memory management method for the multi-core system may include but is not limited to steps S110 to S140.

[0035] Step S110: the master core unit identifies the initial memory management priorities of the master core unit and each slave core unit as the second level; the memory management priorities also include: a first level higher than the second level and a third level lower than the second level.

[0036] Step S120: Determine the system operation status.

[0037] Step S130: updating and determining the current memory management priority of the master core unit and each slave core unit according to the system operation status and the second level.

[0038] Step S140: The memory manager performs memory scheduling and allocation processing according to the memory scheduling and allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates free memory units to the applicant so that the applicant can execute tasks in the task queue; the applicant is a master core unit or a slave core unit.

[0039] Before step S110, the embodiment of the present application also includes: pre-configuration processing of the multi-core system. Specifically, the pre-configuration processing of the multi-core system includes: first, dividing the public memory in the multi-core system into M equal parts, each equal part is the smallest memory unit that can be applied. Second, configuring a bitmap table, each data bit in the bitmap table corresponds to the usage and idle status of a memory unit, when the value of the data bit is 1, it means that the corresponding memory unit has been used and is not idle; when the value of the data bit is 0, it means that the corresponding memory unit is not used and idle; configuring the bitmap table provides a reliable reference for the memory manager to apply for and release memory. Third, configuring a user record table, the user record table is used to record user information using the memory unit, that is, to record which core occupies each used memory unit. Fourth, determining the master core unit and the slave core unit in the multiple core processing units of the multi-core system, wherein the master core unit has the authority to adjust the memory management priority of itself and all other slave core units; and the slave core unit does not have the authority to adjust the memory management priority. Fifth, each core interacts through a message queue. Sixth, the master core unit and all slave core units share the same memory manager, and a mutex is configured in advance to facilitate the use of the mutex to resolve conflicts in the use of the memory manager. Seventh, a preset threshold is configured, which is the minimum amount of memory that a memory unit should occupy. Eighth, the initial memory management priority is configured.

[0040] It can be understood that the memory management priority in step S110 has three levels, and the smaller the value, the higher the priority level.

[0041] It is understandable that the first level is used to indicate that the corresponding applicant is allowed to apply for memory, and can request to release memory units occupied by other applicants when insufficient memory is encountered. The second level is used to indicate that the corresponding applicant is allowed to apply for memory units, and the applicant can apply to release memory units occupied by other applicants when the attempt to apply for memory fails and the amount of occupied memory is less than a preset threshold, but is not allowed to apply for new memory units when the amount of occupied memory is not less than the preset threshold. The third level is used to indicate that the corresponding applicant is not allowed to apply for memory units. The embodiment of the present application configures the memory management priority to provide a reliable reference for the subsequent memory manager to perform memory scheduling and allocation.

[0042] It can be understood that, through step S110, the initial memory management priorities of the master core unit and each slave core unit are all marked as the second level, so as to facilitate subsequent adjustment of the memory management priorities.

[0043] Specifically, the system operation status includes: memory resource usage status, and emergency situations of main core tasks executed by the main core unit.

[0044] It is understandable that the memory resource usage can be reflected by indicators such as memory usage rate and system response time, so this application does not make specific restrictions on how to judge the memory resource usage. The emergency situation of the main core task performed by the main core unit can be reflected by indicators such as task priority and scheduling priority, so this application does not make specific restrictions on how to judge the emergency situation of the main core task in step S120, and does not make specific restrictions on the way to judge the system operation situation.

[0045] Specifically, there are three system operating conditions provided in the embodiments of the present application: one is that memory resources are tight and the main core tasks executed by the main core unit are urgent; the second is that memory resources are tight and the main core tasks executed by the main core unit are not urgent; the third is that memory resources are sufficient.

[0046] According to some embodiments of the present application, step S130 is further explained, and step S130 includes but is not limited to: when the system operation status is: memory resources are tight and the main core task executed by the main core unit is urgent, it is determined that the current memory management priority of the main core unit is increased from the second level to the first level, and the memory management priority of the slave core unit is reduced from the second level to the third level; when the system operation status is: memory resources are tight and the main core task executed by the main core unit is not urgent, it is determined that the current memory management priority of the main core unit and each slave core unit is the second level; when the system operation status is: memory resources are sufficient, it is determined that the current memory management priority of the main core unit and each slave core unit is the second level. The embodiment of the present application re-determines the current memory management priority of the main core unit and each slave core unit through the current system operation status, so as to provide a reliable reference for the subsequent memory manager to perform memory scheduling and allocation, and realize a reliable memory management mechanism for multi-core systems.

[0047] Through step S110 to step S140, when the multi-core system is running, first, the main core unit identifies the initial memory management priority of the main core unit and each slave core unit as the second level; wherein the memory management priority also includes: a first level higher than the second level, and a third level lower than the second level; then, the system operation status is judged; then, according to the system operation status and the second level, the current memory management priority of the main core unit and each slave core unit is updated and determined; a reliable reference is provided for the subsequent memory manager to perform memory scheduling and allocation, thereby realizing reasonable allocation of memory to improve the system memory utilization; finally, the memory manager performs memory scheduling and allocation processing according to the memory scheduling and allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates idle memory units to the applicant so that the applicant can execute the task in the task queue; the applicant is the main core unit or the slave core unit; thereby ensuring that the multi-core system can run efficiently and correctly. Therefore, the embodiment of the present application can improve the system memory utilization and ensure that the multi-core system runs efficiently and correctly.

[0048] In some embodiments, a bitmap table and a user record table are stored in a multi-core system; the bitmap table is used to reflect the idle status of each memory unit; and the user record table is used to record user information using the memory unit. The bitmap table includes the memory address of each memory unit and the data bit corresponding to the memory address. When the value of the data bit is 0, it indicates that the memory unit is idle and not used; when the value of the data bit is 1, it indicates that the memory unit is not idle and is used.

[0049] It is understandable that the memory scheduling and allocation process implemented in the multi-core system is different for different system operation conditions.

[0050] According to some embodiments of the present application, step S140 is further described, wherein the memory manager performs memory scheduling and allocation processing according to the memory scheduling and allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates free memory units to the applicant, including but not limited to the following steps.

[0051] Step S211: When the system operation status is: memory resources are tight and the main core task is urgent, when the main core unit fails to apply for the memory unit, the main core unit determines the target slave core from the slave core units occupying the memory unit according to the bitmap table and the user record table, and the main core unit sends a memory release request to the target slave core as the applicant.

[0052] Step S220: the target slave core responds to the memory release request, performs a first memory release process with the memory manager, obtains free memory units, an updated bitmap table, and an updated user record table, and returns the generated first memory release response to the applicant.

[0053] Step S230: the applicant initiates a memory application request to the memory manager in response to the first memory release response.

[0054] Step S240: the memory manager responds to the memory application request, performs memory allocation processing according to the applicant's current memory management priority, and allocates free memory units to the applicant.

[0055] Step S250: After the main core task processing is completed, the memory management priorities of the main core unit and each slave core unit are restored to the second level, and the memory units are released.

[0056] Specifically, in step S211, when the main core unit applies for a memory unit from the memory manager, but the memory manager returns an empty address, the main core unit confirms that the application for the memory unit has failed; in addition, when the current memory management level of the main core unit is the first level, the main core unit determines the target slave core according to the bitmap table and the user record table, and then, as an applicant, sends a memory release request to the target slave core, so that the target slave core releases the occupied memory space to the main core unit. In this process, the main core unit has priority over the slave core unit in applying for memory space; at this time, when the current memory management level of the slave core unit is the third level, the slave core unit is not allowed to issue a memory application request, suspends the current task, and continues to process other tasks. Even if the slave core unit erroneously issues a memory application request, the memory management module will not respond to the memory application request issued by the slave core unit.

[0057] Through steps S220 to S240, the memory manager and the target slave core cooperate with each other to release memory and allocate idle memory units to the main core unit, ensuring that urgent main core tasks in the main core unit can run efficiently and correctly, which is conducive to the efficient and correct operation of the multi-core system.

[0058] Through step S250, after the urgent main core task is completed, the main core unit restores the memory management priority of the main core unit and each slave core unit to the second level, so that the main core unit will not always occupy the highest priority, but in non-emergency conditions, the main core unit and the slave core unit can flexibly and reasonably apply for memory units from each other.

[0059] It is understandable that, taking a dual-core system as an example, the slave core unit is the initiator of the task and the master core is the processor of the task. In the normal working mode, the slave core unit frequently applies for and releases memory, and even fills up the entire public memory. The master core unit occasionally applies for memory as needed. When entering the emergency working mode, the master core unit will occupy most of the public memory. At this time, the memory management level of the master core unit is increased, and the memory management level of the slave core unit is reduced; reducing the memory competition between the master core unit and the slave core unit, which is conducive to the rational use of system memory and reducing the probability of abnormal operation in multi-core systems.

[0060] Through step S211, step S220 to step S240, when memory resources are tight and the main core task is urgent, the memory management priority can be dynamically adjusted, and idle memory units can be allocated to the main core unit based on the adjusted memory management priority, ensuring that the urgent main core tasks in the main core unit can run efficiently and correctly, which is conducive to the efficient and correct operation of the multi-core system; and reducing the memory contention between the main core unit and the slave core unit, reducing the probability of operation abnormalities in the multi-core system.

[0061] In one embodiment, it should be noted that in a system with three cores or more, if two slave core units compete for memory, and the slave core unit cannot apply for memory, if it is at the third level, it directly abandons the memory application, suspends the current task, and continues to process other matters; if it is at the second level, it obtains the occupied memory and determines whether the occupied memory is less than the preset memory threshold. If so, it requests other slave core units to release the memory, otherwise, it abandons the memory application. When the slave core unit is required to release the memory, it rolls back the operation corresponding to the most recently applied memory and releases the memory; then, it starts again from the rolled back operation. In this way, the conflict of competing for memory between the two slave core units can be resolved, and the normal operation of the system can be guaranteed.

[0062] According to some embodiments of the present application, step S140 is further described, wherein the memory manager responds to the memory scheduling allocation request sent by the applicant, performs memory scheduling allocation processing according to the system operation status, the type of the applicant, and the applicant's current memory management priority, and allocates free memory units to the applicant, and also includes but is not limited to the following steps.

[0063] Step S212: When the system operation status is: sufficient memory resources, or: tight memory resources and the main core task executed by the main core unit is not urgent, according to the second level, the applicant obtains the amount of occupied memory when the application for the memory unit fails; when the amount of occupied memory is less than the preset memory threshold, the applicant sends a memory release request to the target slave core.

[0064] Step S220: the target slave core responds to the memory release request, performs a first memory release process with the memory manager, obtains free memory units, an updated bitmap table, and an updated user record table, and returns the generated first memory release response to the applicant.

[0065] Step S230: the applicant initiates a memory application request to the memory manager in response to the first memory release response.

[0066] Step S240: the memory manager responds to the memory application request, performs memory allocation processing according to the applicant's current memory management priority, and allocates free memory units to the applicant.

[0067] To further illustrate step S212, when the system is running in the following conditions: sufficient memory resources; then the master core unit and the slave core unit do not need to go through the process of applying for memory release, but can directly apply for memory units and directly release the memory units after use, so that the entire multi-core system can operate efficiently. When memory resources are sufficient, the memory management levels of the master core unit and the slave core unit are both at the second level, and the applicant can be either the master core unit or the slave core unit. There is no order of priority when applying for memory, and applications can be made on demand. Similarly, when the system is running in the following conditions: sufficient memory resources, at the second level, when the applicant fails to apply for a memory unit, the applicant obtains the amount of occupied memory. When the amount of occupied memory is less than the preset memory threshold, the applicant sends a memory release request to the target slave core; when the amount of occupied memory is not less than the preset memory threshold, the application for the memory unit is abandoned, and the processing of the current pending task is postponed.

[0068] Further explanation of step S212, when the system operation status is: memory resources are tight and the main core task executed by the main core unit is not urgent; at the second level, when the main core unit fails to apply for the memory unit, the occupied memory amount is obtained, and when the occupied memory amount is less than the preset memory threshold, the main core unit sends a memory release request to the target slave core; when the occupied memory amount is not less than the preset memory threshold, the application for the memory unit is abandoned and the processing of the current task to be processed is postponed.

[0069] Further explanation of step S212, when the system operation status is: memory resources are tight and the main core task executed by the main core unit is not urgent; at the second level, when the slave core unit fails to apply for the memory unit, the occupied memory amount is obtained, and when the occupied memory amount is less than the preset memory threshold, the slave core unit sends a memory release request to the target slave core; when the occupied memory amount is not less than the preset memory threshold, the application for the memory unit is abandoned and the processing of the current task to be processed is postponed.

[0070] Through step S212, step S220 to step S240, the master core unit and the slave core unit can apply for memory units in an orderly manner according to demand, and the memory manager and the target slave core cooperate with each other to release memory, allocate free memory units to the master core unit or the slave core unit, improve system memory utilization, ensure that the master core unit or the slave core unit can run efficiently and correctly, and facilitate the efficient and correct operation of the multi-core system.

[0071] According to some embodiments of the present application, step S220 is further described, and step S220 includes but is not limited to steps S221 to S223.

[0072] Step S221: the target slave core responds to the memory release request, rolls back the operation corresponding to the most recently applied memory unit, and sends a memory release notification to the memory manager.

[0073] Step S222: the memory manager performs memory release processing and table update processing in response to the memory release notification, and obtains an updated bitmap table and an updated user record table.

[0074] Step S223: the target slave core starts to execute the slave core task again from the rolled back operation, generates a first memory release response, and returns the first memory release response to the applicant.

[0075] According to some embodiments of the present application, step S222 includes but is not limited to steps S2221 to S2224.

[0076] Step S2221: the memory manager acquires the mutex lock in response to the memory release notification sent by the applicant; the applicant is the master core unit or the slave core unit.

[0077] Step S2222: Determine a second target data bit with a value of 1 to be allocated among the multiple data bits in the bitmap table, and determine a second memory address of the memory unit to be released according to the second target data bit.

[0078] Step S2223: modify the value of the second target data to 0, clear the user information corresponding to the memory unit to be released in the user record table according to the second memory address, obtain an updated bitmap table and an updated user record table, and release the used memory unit.

[0079] Step S2224: Unlock the mutex lock.

[0080] Through steps S2221 to S2224, the memory manager uses a mutex lock before and after the memory release to avoid request conflicts, which is beneficial to ensuring the normal operation of the multi-core system.

[0081] Through step S221 to step S223, the target slave core responds to the memory release request and cooperates with the memory manager to release the memory to ensure that there are free memory units that can be allocated.

[0082] According to some embodiments of the present application, step S240 is further described, and step S240 includes but is not limited to steps S241 to S246.

[0083] Step S241: the memory manager acquires a mutex in response to a memory application request sent by an applicant; the applicant is a master core unit or a slave core unit.

[0084] Step S242: When it is confirmed that the applicant's current memory management priority is not the third level, a first target data bit with a value of 0 to be allocated is determined among the multiple data bits in the bitmap table.

[0085] Step S243: Determine a first memory address of an idle memory unit in the bitmap table according to the first target data bit.

[0086] Step S244: modify the value of the first target data bit to 1, and modify the user information corresponding to the memory address to be allocated in the user record table according to the application user information carried in the memory application request, to obtain an updated bitmap table and an updated user record table.

[0087] Step S245: Return the first memory address to the applicant to allocate the free memory unit to the applicant.

[0088] Step S246: Unlock the mutex lock.

[0089] Through steps S241 to S246, the memory manager uses a mutex lock before and after applying for memory, thereby avoiding request conflicts; this is beneficial to ensuring the normal operation of the multi-core system.

[0090] like Figure 3 As shown, Figure 3 This is a schematic diagram of a specific process of a memory manager applying for memory provided by an embodiment of the present application.

[0091] Step S301: Acquire a mutex lock;

[0092] Step S302: Obtain the applicant's current memory management level;

[0093] Step S303: determine whether the current memory management level is the third level; if so, jump to step S307 to step S308; if not, jump to step S304;

[0094] Step S304: Acquire and search the bitmap table;

[0095] Step S305: Determine whether there is an idle memory unit; if so, jump to step S306; if not, jump to step S307 to step S308;

[0096] Step S306: Return the first memory address of the free memory unit to the applicant; continue to step S308;

[0097] Step S307: Returning an empty address, the memory unit application fails;

[0098] Step S308: Release the mutex lock.

[0099] The embodiment of the present application sets a dynamically adjustable memory management level. Based on the dynamically adjusted memory management level and preset memory management rules, the memory manager, the main core unit, and the slave core unit cooperate with each other to implement a memory management mechanism for the multi-core system. Under this memory management mechanism, the public memory can be fully utilized, and any core (main core unit or slave core unit) can occupy all the public memory. When there is multi-core competition, coordination and allocation can be carried out according to the current memory management level and preset memory management rules to achieve reasonable allocation of memory. This can improve the system memory utilization and ensure that the multi-core system runs efficiently and correctly.

[0100] It should be emphasized that the memory management method of the embodiment of the present application can be applied not only to multi-core systems, but also to the memory management of single-core multi-tasking systems; the memory management of multi-core systems is the same as the principle of memory management of single-core multi-tasking systems, which will not be repeated here.

[0101] like Figure 4 As shown, Figure 4 This is a hardware structure diagram of an electronic device provided by an embodiment of the present application. The present application also provides an electronic device, including:

[0102] The processor 401 may be implemented by a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0103] The memory 402 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 402 can store an operating system and other application programs. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 402, and the processor 401 calls and executes the memory management method for a multi-core system in the embodiment of this application;

[0104] Input / output interface 403, used to implement information input and output;

[0105] Communication interface 404, used to realize communication interaction between the present apparatus and other devices, which can be realized by wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.);

[0106] A bus 405 that transmits information between various components of the device (e.g., processor 401, memory 402, input / output interface 403, and communication interface 404);

[0107] The processor 401 , the memory 402 , the input / output interface 403 and the communication interface 404 are connected to each other in communication within the device via the bus 405 .

[0108] An embodiment of the present application further provides a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is executed by a processor, the above-mentioned memory management method for a multi-core system is implemented.

[0109] As a non-transient computer-readable storage medium, the memory can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage devices. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof. The device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and are implemented to be located in one place, or may also be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment.

[0110] It will be appreciated by those skilled in the art that all or some of the steps and systems in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or transient medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically include computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0111] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the above-mentioned implementation mode. Technical personnel familiar with the field can also make various equivalent deformations or substitutions without violating the spirit of the present application. These equivalent deformations or substitutions are all included in the scope defined by the present application.

Claims

1. A memory management method for a multi-core system, characterized in that: Applied to a multi-core system, the multi-core system comprises: a memory manager, a plurality of common equally divided memory units, a master core unit and at least one slave core unit; the method comprises: The master core unit marks the initial memory management priorities of the master core unit and each of the slave core units as the second level; the memory management priority also includes: a first level higher than the second level and a third level lower than the second level; Determine the system operation status; update and determine the current memory management priority of the master core unit and each of the slave core units according to the system operation status and the second level; The memory manager performs memory scheduling and allocation processing according to the memory scheduling and allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates the idle memory unit to the applicant so that the applicant can execute the task in the task queue; the applicant is a master core unit or a slave core unit; Among them, the updating and determining of the current memory management priority of the main core unit and each of the slave core units according to the system operation status and the second level includes: when the system operation status is: memory resources are tight and the main core task executed by the main core unit is urgent, determining that the current memory management priority of the main core unit is increased from the second level to the first level, and determining that the memory management priority of the slave core unit is reduced from the second level to the third level.

2. The memory management method for a multi-core system according to claim 1, characterized in that: The updating and determining the current memory management priority of the master core unit and each of the slave core units according to the system operation status and the second level also includes: When the system operation condition is: memory resources are tight and the main core task executed by the main core unit is not urgent, determining that the current memory management priority of the main core unit and each of the slave core units is the second level; When the system operation status is: memory resources are sufficient, it is determined that the current memory management priority of the master core unit and each of the slave core units is the second level.

3. The memory management method for a multi-core system according to claim 2, characterized in that: The multi-core system stores a bitmap table and a user record table; the bitmap table is used to reflect the idle status of each memory unit; the user record table is used to record user information using the memory unit; The memory manager performs memory scheduling and allocation processing according to the memory scheduling and allocation request sent by the applicant, the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates the idle memory unit to the applicant, including: When the system is running in the following conditions: memory resources are tight and the master core has an urgent task, and the master core unit fails to apply for the memory unit, the master core unit determines a target slave core from the slave core units occupying the memory unit according to the bitmap table and the user record table, and the master core unit, as an applicant, sends a memory release request to the target slave core; The target slave core performs a first memory release process with the memory manager in response to the memory release request, obtains free memory units, an updated bitmap table, and an updated user record table, and returns the generated first memory release response to the applicant; The applicant initiates a memory application request to the memory manager in response to the first memory release response; The memory manager responds to the memory application request, performs memory allocation processing according to the current memory management priority of the applicant, and allocates the idle memory unit to the applicant; When the main core task processing is completed, the memory management priority of the main core unit and each of the slave core units is restored to the second level.

4. The memory management method for a multi-core system according to claim 3, characterized in that: The memory manager responds to the memory scheduling allocation request sent by the applicant, performs memory scheduling allocation processing according to the system operation status, the type of the applicant, and the current memory management priority of the applicant, and allocates the idle memory unit to the applicant, and also includes: When the system operation condition is: sufficient memory resources, or: insufficient memory resources and the main core task performed by the main core unit is not urgent, according to the second level, the applicant obtains the amount of occupied memory when the application for the memory unit fails; When the amount of occupied memory is less than a preset memory threshold, the applicant sends a memory release request to the target slave core; The target slave core performs a first memory release process with the memory manager in response to the memory release request, obtains free memory units, an updated bitmap table, and an updated user record table, and returns the generated first memory release response to the applicant; The applicant initiates a memory application request to the memory manager in response to the first memory release response; The memory manager responds to the memory application request, performs memory allocation processing according to the current memory management priority of the applicant, and allocates the idle memory unit to the applicant.

5. The memory management method for a multi-core system according to claim 3 or 4, characterized in that: The target slave core performs a first memory release process with the memory manager in response to the memory release request, obtains free memory units, an updated bitmap table, and an updated user record table, and returns the generated first memory release response to the applicant, including: The target slave core, in response to the memory release request, rolls back the operation corresponding to the newly applied memory unit and sends a memory release notification to the memory manager; The memory manager performs memory release processing and table update processing in response to the memory release notification to obtain an updated bitmap table and an updated user record table; The target slave core restarts executing the slave core task from the rolled back operation, generates the first memory release response, and returns the first memory release response to the applicant.

6. The memory management method for a multi-core system according to claim 3 or 4, characterized in that: The bitmap table includes the memory address of each memory unit and the data bit corresponding to the memory address, and when the value of the data bit is 0, it indicates that the memory unit is idle and not in use; The memory manager performs memory allocation processing in response to the memory application request according to the current memory management priority of the applicant, and allocates the idle memory unit to the applicant, including: The memory manager acquires a mutex in response to the memory application request sent by an applicant; the applicant is the master core unit or the slave core unit; When it is confirmed that the current memory management priority of the applicant is not the third level, determining a first target data bit to be allocated having a value of 0 among the plurality of data bits in the bitmap table; determining a first memory address of an idle memory cell in the bitmap table according to the first target data bit; Modify the value of the first target data bit to 1, and modify the user information corresponding to the memory address to be allocated in the user record table according to the application user information carried in the memory application request, to obtain an updated bitmap table and an updated user record table; Returning the first memory address to the applicant to allocate the free memory unit to the applicant; Unlocks the mutex.

7. The memory management method for a multi-core system according to claim 5, characterized in that: The bitmap table includes the memory address of each memory unit and the data bit corresponding to the memory address, and when the value of the data bit is 1, it indicates that the memory unit is not idle and is used; The memory manager performs memory release processing and table update processing in response to the memory release notification to obtain an updated bitmap table and an updated user record table, including: The memory manager acquires a mutex in response to the memory release notification sent by the applicant; the applicant is a master core unit or a slave core unit; Determine a second target data bit to be allocated having a value of 1 among the plurality of data bits in the bitmap table, and determine a second memory address of the memory unit to be released according to the second target data bit; Modify the value of the second target data to 0, clear the user information corresponding to the memory unit to be released in the user record table according to the second memory address, obtain an updated bitmap table and an updated user record table, and release the used memory unit; Unlocks the mutex.

8. A multi-core system, characterized in that: include: A memory manager, a plurality of common equally divided memory units, a master core unit and at least one slave core unit; The memory manager, the master core unit, and the slave core unit cooperate with each other to execute the memory management method for a multi-core system as described in any one of claims 1 to 7.

9. An electronic device, characterized in that: It includes at least one processor and a memory for communicating with the at least one processor; the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the memory management method for a multi-core system as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the memory management method for a multi-core system as described in any one of claims 1 to 7.

Citation Information

Patent Citations

  • Asynchronous parallel graph computing thread throttling optimization method for multi-core system

    CN116775290A

  • Multi-core MCU monitoring method and device, vehicle and readable storage medium

    CN117312092A