A memory management method of a real-time operating system, a real-time operating system and a storage medium

Abstract

The application discloses a memory management method of a real-time operating system, a real-time operating system and a storage medium, and belongs to the technical field of memory management of real-time operating systems. The technical problem to be solved is that when a memory pool is not used, memory fragmentation is high and resource utilization is low. The technical solution is as follows: whether the memory pool is used is determined according to configuration; if the memory pool is not used, the following memory allocation strategy is enabled: when an idle thread is initialized, a dynamic memory monitoring mechanism is added; the dynamic memory monitoring mechanism is used to dynamically monitor memory usage of remaining task threads other than the idle thread; and according to the memory usage of the remaining task threads other than the idle thread, memory of the corresponding threads is dynamically recycled or released to the corresponding threads.

Description

Technical Field

[0001] This invention relates to the field of memory management technology for real-time operating systems, and more particularly to a memory management method for a real-time operating system, a real-time operating system, and a storage medium. Background Technology

[0002] A Real-Time Operating System (RTOS) is an operating system that, when external events or data occur, can accept them and process them quickly enough. The results of this processing can then be used to control the production process or provide a rapid response to the processing system within a specified timeframe. It can allocate all available resources to complete real-time tasks and control all real-time tasks to run in a coordinated manner. Providing timely response and high reliability are its main characteristics.

[0003] Current embedded real-time system memory allocation methods mainly achieve this through the following steps:

[0004] 1. When the system actively requests heap memory, if the system is not using a memory pool, the operating system will directly allocate the requested amount of memory from the heap memory space. If the system is using a memory pool, it will directly allocate the corresponding memory block from the memory pool.

[0005] 2. When releasing memory, if the system is not using a memory pool, the operating system will directly release the memory back to the corresponding heap memory space. If the system is using a memory pool, the memory block will be directly released and returned to the corresponding memory pool.

[0006] This current memory allocation method has the following problems: Firstly, when chip resources are scarce, using a memory pool would result in too few resources being allocated. Furthermore, using a memory pool would not only increase chip consumption but also occupy a significant amount of space.

[0007] Secondly, when chip resources are scarce, if a memory pool is used, some small memory fragments will appear. Because a memory pool is used, these small memory fragments cannot be reclaimed. In this case, the resources are originally sufficient but cannot be used normally.

[0008] Third, when chip resources are scarce, if too much heap memory is requested when not using a memory pool, it can also cause memory fragmentation, thereby reducing resource utilization.

[0009] The relevant patent literature has explored this issue: For example, Chinese patent application CN101329655B discloses a memory management method and device. The method divides the system memory area into several memory pools; determines the corresponding memory pool based on the size of memory requests or releases; obtains the number of memory blocks the system currently needs in that memory pool; obtains the sum of the number of free memory blocks that other memory pools can currently provide to that memory pool; calculates the difference between the two; compares this difference with the current optimal value of the number of memory blocks in that memory pool, and takes the larger of the two as the new current optimal value; after the system has run for a predetermined time, the obtained current optimal value is taken as the optimal value of the number of memory blocks in that memory pool; and allocates memory based on the obtained optimal values ​​of the number of memory blocks in all memory pools. This invention can reasonably set the size of the memory pool in an embedded real-time operating system, reducing wasted memory fragmentation.

[0010] For example, Chinese patent application CN113535597B, "Memory Management Method, Memory Management Unit, and IoT Device," discloses a memory management method comprising: responding to a memory allocation instruction; determining at least one memory block address corresponding to at least one free memory block with contiguous storage space, based on the size of the memory to be allocated; allocating memory space of the size of the memory to be allocated based on an offset address of at least one memory block fragment currently corresponding to the at least one memory block address, thereby obtaining a second offset address of the at least one memory block fragment after memory allocation; and updating the first offset address of the at least one memory block fragment using the second offset address of the at least one memory block fragment after memory allocation. Since a memory block fragment has a smaller storage space than a memory block, managing memory space based on the offset address of the memory block fragment corresponding to the memory block effectively solves the problem of memory fragmentation.

[0011] The existing technology has at least the following unresolved technical problems or defects: The first method only applies to scenarios using memory pools. When chip resources are scarce, the problem of low memory utilization cannot be solved even without using a memory pool. The second method is applicable to heap memory scenarios, but it only reduces memory fragmentation through memory allocation. However, it cannot reclaim existing memory fragments, thus failing to address the resource waste caused by memory fragmentation. Summary of the Invention

[0012] The purpose of this invention is to provide: A memory management method for an RTOS, and related technologies, to solve technical problems such as resource waste caused by memory fragmentation, or a combination thereof.

[0013] Terminology Explanation: Unless otherwise defined, all technical terms in this document have the same meanings as commonly understood by one of ordinary skill in the art to which the subject matter of the claims pertains. Unless otherwise stated, all patents, patent inventions, and publications cited in this document are incorporated herein by reference in their entirety. If multiple definitions exist for terms in this document, the definitions in this chapter shall prevail.

[0014] It should be understood that the above brief description and the following detailed description are exemplary and for illustrative purposes only, and do not limit the subject matter of the invention in any way. In this invention, the singular is used in conjunction with the plural unless otherwise specifically stated. It should also be noted that, unless otherwise stated, the use of “or” or “or” means “and / or”. Furthermore, the use of the term “comprising” and other forms such as “including,” “containing,” and “contains” are not limiting.

[0015] Unless otherwise stated, conventional methods within the scope of the art shall be used.

[0016] The term "memory" used in this article refers to a crucial component of a computer, also known as internal memory or main memory. It temporarily stores data processed by the CPU, as well as data exchanged with external storage devices such as hard drives. It acts as a bridge between external storage and the CPU; all programs run within memory, and the performance of memory directly impacts the overall performance of the computer. Once the computer starts running, the operating system retrieves the necessary data from memory to the CPU for processing. After the processing is complete, the CPU sends the result back. The operation of memory determines the overall speed of the computer.

[0017] The term "memory pool" used in this article refers to a technique that optimizes memory management by pre-allocating fixed-size memory blocks, also known as fixed-size block planning. Its core mechanism involves pre-allocating an equal number of memory blocks for backup and allocating them on demand to reduce memory fragmentation and improve allocation efficiency. It is commonly used in scenarios requiring a stable memory supply. In blockchain, memory pools prevent network congestion caused by dust attacks by limiting the maximum number of transactions and transaction fees. In real-time systems, this technique avoids performance issues caused by frequently allocating memory of varying sizes. The operating system kernel implements memory pools using the `mempool_t` type, using `mempool_create` to create a memory pool with a specified minimum number of objects, and using `mempool_alloc` and `mempool_free` for object allocation and release. The MindSpore framework's Ascend processor provides a memory pool management approach, supporting users to request large blocks of memory at once and allocate them secondaryly. It dynamically expands the minimum memory block size to include 256MB and 8MB. This framework implements memory allocation, release, and reset functions through the `AscendMemoryPool` class, and constrains memory addresses and sizes to prevent out-of-bounds access. The memory pool supports adjusting its capacity via mempool_resize and reclaiming resources via mempool_destroy, but this results in more memory fragments after reclamation, leading to reduced resource utilization.

[0018] The term "idle thread" used in this article refers to a special system thread in the operating system kernel. When no other processes or threads are available to run on the CPU, an idle thread is scheduled to execute to prevent the CPU from idling. A thread is the smallest unit of computation that the operating system can schedule. It is contained within a process and is the actual unit of operation within that process. A thread refers to a single, sequential flow of control within a process. Multiple threads can run concurrently within a process, each executing different tasks in parallel. In Unix System V and SunOS, they are also called lightweight processes, but the term "lightweight process" more often refers to kernel threads, while user threads are simply called threads.

[0019] The term "hook function" used in this article refers to a component of the Windows message handling mechanism. It monitors and modifies the message flow by intercepting system or process event messages, and is divided into two categories: local hooks (thread-level) and global hooks (system-level). Essentially, it is a predefined callback function, using `SetWindowsHookEx`, `UnhookWindowsHookEx`, and `CallNextHookEx` to perform hooking operations. Global hooks need to be encapsulated in a dynamic link library. This mechanism is based on an event-driven architecture, and the message processing flow is: system queue → program queue → hook interception → delivery to the target window. Specific hook types supported by the system include `WH_KEYBOARD` (keyboard messages) and `WH_MOUSE` (mouse events), among others. Log hooks and replay hooks must reside within the installation thread to maintain event order.

[0020] The term "header structure" used in this article refers to the memory header structure, which is a data structure used in memory management to describe the state, size, or ownership of memory blocks. In operating system kernels or driver development, this type of structure is often used as a basic component of the memory management unit.

[0021] In a first aspect, the present invention provides: a memory management method for a real-time operating system, comprising: Determine whether to use a memory pool based on the configuration. If not, enable the following memory allocation strategy: Add a dynamic memory monitoring mechanism when initializing the idle thread; The memory usage of task threads other than the idle thread is dynamically monitored using a dynamic memory monitoring mechanism. Based on the memory usage of task threads other than the idle thread, the memory of the corresponding thread is dynamically reclaimed or released to the corresponding thread.

[0022] In the technical solution provided in the first aspect of the present invention, the preferred solution includes: The first preferred solution: The dynamic memory monitoring mechanism works as follows: When the user starts other task threads and those threads operate on memory, the idle thread obtains the memory usage of the corresponding threads in real time.

[0023] In a further preferred embodiment, the idle thread monitors stack usage in real time through hook functions to obtain the memory usage of the corresponding thread.

[0024] More preferably, the memory usage statistics are obtained by using a sliding window filter to analyze the memory usage of a task thread after it has run for a preset time, and the statistical results are used as the actual memory usage of the thread.

[0025] More preferably, when the monitored memory allocation exceeds the memory usage threshold, the memory of the corresponding thread is dynamically reclaimed and released; when the monitored memory allocation falls short of the memory usage threshold, memory is dynamically allocated to the corresponding thread for memory expansion.

[0026] More preferably, the memory difference threshold is equal to the dynamic threshold plus a preset threshold, wherein the dynamic threshold is calculated by the average value of the data in the sliding window.

[0027] More preferably, for any task thread other than the idle thread, each allocated memory has a header structure, which includes members, total memory size, sliding window array windows, starting address and size of allocated memory, and the idle thread performs dynamic memory management based on the information recorded in the header structure.

[0028] More preferably, after memory expansion, the data in the header structure file is recalculated based on the newly allocated memory size to obtain the starting address and size of the newly allocated memory.

[0029] More preferably, when the task thread uses memory, it dynamically marks the header structure of the memory. Each time the memory is accessed, the idle thread operates on the header structure according to the stack usage monitored by the hook function to obtain the corresponding memory usage.

[0030] Secondly, the present invention provides a real-time operating system that uses the memory management method of the real-time operating system described above for memory management.

[0031] Thirdly, the present invention provides: a storage medium storing a computer program, wherein the computer program, when executed, can implement the memory management method of the real-time operating system described above.

[0032] Embodiment 1 of this invention at least supports the protection scope of the above-mentioned memory management method of real-time operating system.

[0033] The present invention has at least the following beneficial effects: Compared with existing technologies, the present invention has better technical effects in memory reclamation or expansion, reducing memory fragmentation and improving memory utilization without using a memory pool.

[0034] Furthermore, based on the present invention: Compared with existing technologies, this invention provides a technical solution with a different technical concept, and its technical effect is equivalent to or slightly improved by existing technologies. The difference between the technical concept of this invention and existing technologies includes, but is not limited to, using idle processes for memory management. When the difference between the memory allocated to a task thread and the actual memory used exceeds a preset memory threshold, memory is reclaimed or expanded. This achieves memory reclamation or expansion when the memory pool is not in use, reduces memory fragmentation, and improves memory utilization. Detailed Implementation

[0035] The following non-limiting embodiments are intended to enable those skilled in the art to gain a more comprehensive understanding of the present invention, but do not limit the invention in any way. The following content is merely an exemplary description of the scope of protection claimed by the present invention, and those skilled in the art can make various changes and modifications to the present invention based on the disclosed content, and such changes should also fall within the scope of protection claimed by the present invention.

[0036] The present invention will be further described below by way of specific embodiments.

[0037] Example 1 The memory management method of the real-time operating system of the present invention will be described in detail below with reference to an embodiment of the present invention.

[0038] This invention discloses a memory management method for a real-time operating system, comprising: Determine whether to use a memory pool based on the configuration. If not, enable the following memory allocation strategy: Add a dynamic memory monitoring mechanism when initializing the idle thread; The memory usage of task threads other than the idle thread is dynamically monitored using a dynamic memory monitoring mechanism. Based on the memory usage of task threads other than the idle thread, the memory of the corresponding thread is dynamically reclaimed or released to the corresponding thread.

[0039] In this embodiment, the dynamic memory monitoring mechanism is preferably implemented as follows: when the user starts other task threads and those threads operate on memory, the idle thread obtains the memory usage of the corresponding threads in real time.

[0040] In this embodiment, more preferably, the idle thread monitors stack usage in real time through hook functions to obtain the memory usage of the corresponding thread.

[0041] In this embodiment, it is further preferred that the memory usage statistics are performed on the memory usage of a certain task thread after running for a preset time, and the statistics are performed using a sliding window filter. The obtained statistical results are used as the actual memory usage of the thread.

[0042] In this embodiment, more preferably, when the monitored memory difference threshold is exceeded between the allocable memory and the actual memory used, the memory of the corresponding thread is dynamically reclaimed and released; when the monitored memory difference threshold is exceeded between the allocated memory and the actual memory needed, memory is dynamically allocated to the corresponding thread for memory expansion.

[0043] In this embodiment, the memory difference threshold is further preferably equal to the dynamic threshold plus the preset threshold, wherein the dynamic threshold is calculated by the average value of the data in the sliding window.

[0044] In this embodiment, it is further preferred that for any task thread other than the idle thread, each allocated memory has a header structure. The header structure includes members, total memory size (size), sliding window array (windows), starting address and size of allocated memory. The idle thread performs dynamic memory management based on the information recorded in the header structure.

[0045] In this embodiment, the header structure further preferably includes members, total memory size (size), sliding window array (windows), starting address and size of allocated memory; wherein the total memory size is the requested memory size, the sliding window is the cache array during calculation, the starting address is the starting address of the requested address, and the size is the size used.

[0046] Each time malloc is called, data is added to the sliding window array `window`, while old data that has been moved out of the sliding window is processed. Then, the dynamic threshold is calculated using the data value in the current sliding window, and a preset threshold is added to obtain the memory difference threshold. If the memory difference threshold is larger than the total memory size `size`, memory equal to the difference between the memory difference threshold and the total memory size `size` is dynamically allocated to the corresponding thread for memory expansion. Otherwise, memory is allocated. The members in the header structure are added or subtracted according to the requested memory size, the remaining memory size, and the memory difference threshold.

[0047] The dynamic monitoring process includes: adding corresponding hook functions `hook(uint32_t size, uint8_t flag)` to the `malloc()` and `free()` functions to maintain a global static memory header structure. The members of this header structure are then added or subtracted. For example, when allocating 1000MB of memory, the header structure retrieves the starting address and total memory size (the allocated memory size, 1000MB). When the thread actually allocates memory, it retrieves the allocated size from this 1000MB header structure, sets the used memory to this value (the allocated size), and adds this value to the sliding window. The idle thread then performs calculations during idle time and obtains a memory difference threshold. If the difference exceeds the threshold, the space allocated to this thread is released back to the system; if it is less, the thread requests the difference from the system. Finally, the members of the header structure are added or subtracted based on the allocated memory size (total memory size), the remaining memory size, and the memory difference threshold. This entire process is executed within the task thread context.

[0048] The header structure modifies the memory usage size and the sliding window value within the thread task context. The idle thread is only responsible for the dynamic changes in the header structure. Based on the information in the header structure, the idle thread calculates a dynamic threshold using the sliding window, then obtains a memory difference threshold, and finally uses this threshold to dynamically allocate and release memory, dynamically calculating memory changes and setting the header structure accordingly.

[0049] When the idle thread is idle, it directly accesses the memory header structure and puts each malloc() function call into a sliding window. Each data point is the size of the memory requested by the thread. Since the thread will release memory, it only needs to count the size of the requested memory to dynamically control the total size of the thread. The sliding window size is set to 10. When the data in the sliding window corresponding to the malloc() function is insufficient, it fills the window sequentially. When there is enough data, it discards the outermost data in the malloc() function outside the sliding window sequentially.

[0050] In this embodiment, more preferably, after memory expansion, the data in the header structure file is recalculated based on the newly allocated memory size to obtain the starting address and size of the newly allocated memory.

[0051] In this embodiment, more preferably, when the task thread uses memory, it dynamically marks the header structure of the memory. Each time the memory is accessed, the idle thread operates on the header structure according to the stack usage monitored by the hook function to obtain the corresponding memory usage.

[0052] In this embodiment, the dynamic memory reclamation process is as follows: The sliding window size is set to 10. When the idle thread reaches this size, it calculates the sliding window size by adding the data from data 1 to data 10 in the sliding window and then dividing by 10. This value is set as the dynamic threshold. Then, based on the obtained memory difference threshold, the corresponding memory is dynamically released and reclaimed. For example, if 1024M of memory is initially allocated and 512M is used, the calculated memory difference threshold is 100M. In this case, 1024-512-100M=412M of memory needs to be reclaimed. Similarly, when 1000M of memory is used, the memory difference threshold is also 100M, so 1000+100-1024=76M of memory needs to be dynamically released.

[0053] Finally, it should be noted that the above content is only used to illustrate the technical solution of the present invention, and is not intended to limit the scope of protection of the present invention. Simple modifications or equivalent substitutions made by those skilled in the art to the technical solution of the present invention do not depart from the essence and scope of the technical solution of the present invention.

Claims

1. A memory management method for a real-time operating system, characterized in that, include: Determine whether to use a memory pool based on the configuration. If not, enable the following memory allocation strategy: Add a dynamic memory monitoring mechanism when initializing the idle thread; The memory usage of task threads other than the idle thread is dynamically monitored using a dynamic memory monitoring mechanism. Based on the memory usage of task threads other than the idle thread, the memory of the corresponding thread is dynamically reclaimed or released to the corresponding thread. The dynamic memory monitoring mechanism works as follows: when a user starts other task threads and those threads operate on memory, the idle thread monitors the stack usage in real time through hook functions to obtain the memory usage of the corresponding threads.

2. The memory management method for a real-time operating system according to claim 1, characterized in that, The memory usage statistics are calculated based on the memory usage of a specific task thread after a preset running time. A sliding window filter is used for the statistical analysis, and the results are taken as the actual memory usage of that thread.

3. The memory management method for a real-time operating system according to claim 2, characterized in that, When the monitored memory allocation exceeds the memory usage threshold, the memory of the corresponding thread is dynamically reclaimed and released. When the monitored memory allocation falls short of the memory usage threshold, memory is dynamically allocated to the corresponding thread for memory expansion. The memory difference threshold is equal to the dynamic threshold plus the preset threshold, wherein the dynamic threshold is calculated by the average value of the data in the sliding window.

4. The memory management method for a real-time operating system according to claim 3, characterized in that, For any task thread other than the idle thread, each allocated memory has a header structure. The header structure includes members, total memory size (size), sliding window array (windows), starting address and size of the allocated memory. The idle thread performs dynamic memory management based on the information recorded in the header structure.

5. The memory management method for a real-time operating system according to claim 4, characterized in that, After memory expansion, the data in the header structure file is recalculated based on the newly allocated memory size to obtain the starting address and size of the newly allocated memory.

6. The memory management method for a real-time operating system according to claim 4, characterized in that, When a task thread uses memory, it dynamically modifies the contents recorded in the memory header structure. Each time an action is taken on memory, the idle thread operates on the header structure based on the stack usage monitored by the hook function to obtain the corresponding memory usage information.

7. A real-time operating system, characterized in that, Memory management is performed using the memory management method of the real-time operating system according to any one of claims 1-6.

8. A storage medium, characterized in that, The device stores a computer program that, when executed, implements the memory management method of the real-time operating system as described in any one of claims 1-6.