Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the method of LiteOS memory management". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the method of LiteOS memory management".

1. Memory management of LiteOS kernel 1.1. Memory management

In the process of running the system, the size of some memory space is uncertain, such as some data buffers, so the system needs to provide the management ability of memory space, and users can apply for the required memory space when they are in use. release the space after use so that it can be used again.

The memory management module of Huawei LiteOS manages the use of memory by users and OS through the request / release operation of memory, which optimizes the utilization and efficiency of memory, and solves the problem of memory fragmentation of the system to the maximum extent.

1.2. Dynamic memory management

Dynamic memory management, that is, in the case of sufficient memory resources, from a relatively large piece of continuous memory (memory pool) configured by the system, allocate blocks of memory of any size according to the needs of users. When the user does not need the memory block, it can be released back to the system for next use.

Compared with static memory, the advantage of dynamic memory management is that it is allocated on demand, while the disadvantage is that it is prone to fragmentation in the memory pool.

LiteOS dynamic memory supports two standard algorithms, DLINK and BEST LITTLE.

1.2.1. DLINK dynamic memory management algorithm

The DLINK dynamic memory management structure is shown in the following figure:

The first part

The starting address of heap memory (also known as memory pool) and the total size of the heap area.

Part II

Itself is an array, each element is a two-way linked list, and the control heads of all free nodes are sorted and hung in the two-way linked list of this array.

Part III

It takes up a large part of the memory pool and is the actual area used to store each node.

1.2.2. BEST LITTLE algorithm (key point)

LiteOS's dynamic memory allocation supports the best adaptation algorithm, namely BEST LITTLE, in which the smallest and most suitable memory block in the memory pool is selected for each allocation.

Based on the optimal adaptation algorithm, LiteOS dynamic memory management adds SLAB mechanism to allocate fixed-size memory blocks, thus reducing the possibility of producing memory fragments.

The SLAB mechanism in LiteOS memory management supports the number of configurable SLAB CLASS and the maximum space per CLASS.

The number of SLAB CLASS is 4 and the maximum space of each CLASS is 512 bytes as an example to illustrate the SLAB mechanism:

There are 4 SLAB CLASS in the memory pool, the total allocable size of each SLAB CLASS is 512 bytes, the first SLAB CLASS is divided into 32 16-byte SLAB blocks, the second SLAB CLASS is divided into 16 32-byte SLAB blocks, the third SLAB CLASS is divided into 8 64-byte SLAB blocks, and the fourth SLAB CLASS is divided into 4 128byte SLAB blocks. These four SLAB CLASS are allocated according to the best fit algorithm from the memory pool.

When initializing memory management, first initialize the memory pool, then apply for 4 SLAB CLASS according to the best adaptation algorithm in the initialized memory pool, and then initialize 4 SLAB CLASS one by one according to the SLAB memory management mechanism.

Each time you apply for memory, you should first apply in the best SLAB CLASS that meets the requested size (for example, if a user applies for 20 bytes of memory, he or she applies in a SLAB CLASS with a SLAB block size of 32 bytes). If the application is successful, the whole block of SLAB memory will be returned to the user and the whole block will be reclaimed when it is released. If there are no blocks of memory that can be allocated in the qualified SLAB CLASS, continue to apply to the memory pool according to the best adaptation algorithm. It is important to note that if there are no SLAB blocks available in the current SLAB CLASS, you will apply directly to the memory pool instead of continuing to apply to the SLAB CLASS with more SLAB block space.

When releasing memory, first check whether the released memory block belongs to SLAB CLASS, and if it is the memory block of SLAB CLASS, return it to the corresponding SLAB CLASS, otherwise return it to the memory pool.

1.2.3. Selection of two dynamic memory Management methods

The method of LiteOS dynamic memory management is enabled by the method defined by macros and configured in the target_config.h file in OS_CONFIG under the user's project directory.

In this file, find the following two macro definitions, which are enabled if set to YES:

Enable BEST LITTLE algorithm

# define LOSCFG_MEMORY_BESTFIT YES

Enable the SLAB mechanism

# define LOSCFG_KERNEL_MEM_SLAB YES1.3. Application scenario of dynamic memory Management

The main task of memory management is to dynamically divide and manage the memory interval allocated by users.

Dynamic memory management is mainly used in scenarios where users need to use blocks of memory of different sizes. When users need to allocate memory, they can request a specified size of memory block through the dynamic memory request function of the operating system. Once used, the occupied memory is returned through the dynamic memory release function so that it can be reused.

two。 Dynamic memory management API

The memory management module in the Huawei LiteOS system manages the memory resources of the system, and mainly provides the functions of initialization, allocation and release of memory.

The memory management API provided in the Huawei LiteOS system starts with LOS, but these API are complex to use, so we use the unified API interface provided by Huawei IoT Link SDK for experiments. The underlying implementation of these interfaces has been implemented using API provided by LiteOS, which is more concise for users. The API list is as follows:

The api API of osal is declared in, and the header file needs to be included to use the related API. For more information on the parameters of the function, please refer to the declaration of the header file.

The relevant interfaces are defined in osal.c, and the LiteOS-based interfaces are implemented in the liteos_imp.c file:

The API name function describes that osal_malloc applies for allocation of dynamic memory space by byte osal_free releases the allocated dynamic memory space osal_zalloc applies for allocation of dynamic memory space by byte, and if the allocation is successful, all values of this piece of memory are initialized for 0osal_realloc to re-apply for allocation of dynamic memory space osal_calloc request to allocate num dynamic memory space of length size

This API is used regardless of which dynamic memory management algorithm you choose to use.

2.1. Osal_malloc

API osal_malloc is used to allocate dynamic memory space by byte request. The API prototype is as follows:

Void * osal_malloc (size_t size) {void * ret = NULL; if ((NULL! = s_os_cb) & & (NULL! = sroomosroomcb-> ops) & & (NULL! = slicosroomcb-> ops- > malloc)) {ret = slicosroomcb-> ops- > malloc (size);} return ret;}

The parameters of this API are described in the following table:

Parameter describes the amount of memory applied for allocation by size. The returned value per Byte is allocated successfully-returns the memory block pointer

Allocation failed-returns NULL2.2. Osal_free

The osal_free API is used to free the allocated dynamic memory space. The interface prototype is as follows:

Void osal_free (void * addr) {if ((NULL! = s_os_cb) & & (NULL! = sroomosroomcb-> ops) & & (NULL! = slicosroomcb-> ops- > free)) {scompresosroomcb-> ops- > free (addr);} return;}

After the memory block free, remember to make the memory block pointer NULL, otherwise it will become a wild pointer!

The parameters of this API are described in the following table:

Parameter description addr dynamically allocates memory space with a pointer return value that has no return value of 2.3. Osal_zalloc

API osal_zalloc is used to allocate dynamic memory space by byte request. If the allocation is successful, all values of this memory block are initialized to 0. The API prototype is as follows:

Void * osal_zalloc (size_t size) {void * ret = NULL; if ((NULL! = s_os_cb) & & (NULL! = sroomosroomcb-> ops) & & (NULL! = slicosroomcb-> ops- > malloc)) {ret = slicosroomcb-> ops- > malloc (size); if (NULL! = ret) {memset (ret,0,size) }} return ret;}

The parameters of this API are described in the following table:

Parameter describes the amount of memory applied for allocation by size. The returned value per Byte is allocated successfully-returns the memory block pointer

Allocation failed-returns NULL2.4. Osal_realloc

API osal_realloc is used to reapply for dynamic memory space allocation. The API prototype is as follows:

Void * osal_realloc (void * ptr,size_t newsize) {void * ret = NULL; if ((NULL! = s_os_cb) & & (NULL! = sroomosroomcb-> ops) & & (NULL! = slicosroomcb-> ops- > realloc)) {ret = slicosroomcb-> ops- > realloc (ptr,newsize);} return ret;}

The parameters of this API are described in the following table:

Parameter describes the pointer that ptr has allocated memory space. Newsize requests the new memory size allocated. The returned value per Byte is allocated successfully-returns the memory block pointer.

Allocation failed-returns NULL2.5. Osal_calloc

API osal_calloc is used to apply for allocation of num dynamic memory space with a length of size. The API prototype is as follows:

Void * osal_calloc (size_t n, size_t size) {void * p = osal_malloc (n * size); if (NULL! = p) {memset (p, 0, n * size);} return p;}

The parameters of this API are described in the following table:

Parameter describes the number of memory blocks applied for allocation. Size applies for the memory size of each memory block allocated. The unit Byte return value is allocated successfully-returns the memory block pointer.

Allocation failed-returns NULL3. Hands-on experiment-- testing the maximum byte experiment content of dynamic memory allocation

In this experiment, we will create a task, starting from the minimum bytes, constantly apply for the allocation of memory, release the allocated memory, until the application fails, and observe the maximum bytes that can be applied in the serial port terminal.

Experimental code

First of all, open the HelloWorld project used in the previous article, and carry out experiments based on this project.

Right-click the Demo folder and create a new folder called osal_kernel_demo to store the kernel's experimental files (ignore this step if you already have one).

Next, create a new experimental file, osal_mem_demo.c, in this folder, and start writing code:

/ * to use the osal interface, you need to include the header file * / # include / * Task entry function * / static int mem_access_task_entry () {uint32_t I = 0; / / Loop variable size_t mem_size; / / the requested memory block size uint8_t* mem_ptr = NULL / / memory block pointer while (1) {/ * doubles the size of the requested memory per cycle * / mem_size = 1 access 1 bytes memory requests free memory requests access 2 bytes memory requests free memory blocks access 4 bytes memory blocks free memory pointers access 8 bytes memory free memory pointers access 16 bytes memory blocks free memory requests access 32 bytes memory requests free memory requests access 64 bytes memory free Memory success!access 128 bytes memory success!free memory success!access 256 bytes memory success!free memory success!access 512 bytes memory success!free memory success!access 1024 bytes memory success!free memory success!access 2048 bytes memory success!free memory success!access 4096 bytes memory success!free memory success!access 8192 bytes memory success!free memory success!access 16384 bytes memory success!free memory success!access 32768 bytes memory failed!

As you can see, after the system starts, the version number is printed first, the priority of the serial port shell is 10, and the shell information is printed first, then the memory request task is created and executed, and the maximum space that can be applied on the chip is 16384 bytes.

Thank you for your reading, the above is the content of "what is the method of LiteOS memory management". After the study of this article, I believe you have a deeper understanding of what the method of LiteOS memory management is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.