[mem] Remove useless code And Update mem documentation

documentation/memory/memory.md

@@ -14,7 +14,7 @@
 
 1) Time for allocating memory must be deterministic. The general memory management algorithm needs to find a free memory block that is compatible with the data according to the length of the data to be stored, and then store the data therein. The time it takes to find such a free block of memory is uncertain, but for real-time systems, this is unacceptable. Real-time systems require that the allocation process of the memory block is completed within a predictable certain time, otherwise the response of a real-time task to an external event will become indeterminable.
 
 2) As memory is constantly being allocated and released, the entire memory area will fragment. This means that instead of one large continuous block, the memory area will have small memory blocks taken up inbetween, limiting the largest possible contiguous block which the code can ask for. For general-purpose systems, this issue can be solved by rebooting the system (once every month or once per few months). However, this solution is unacceptable for embedded systems that need to work continuously in the field work all the year round.
 
 3) The resource environment of embedded system is also different. Some systems have relatively tight resources, only tens of kilobytes of memory are available for allocation, while some systems have several megabytes of memory. This makes choosing an efficient memory allocation algorithm for these different systems more complicated.
 
@@ -24,7 +24,7 @@
 
 The second is allocation management for large memory blocks (slab management algorithm);
 
 The third is allocation management for multiple memory heaps (memheap management algorithm)
 
 Memory Heap Management
 ----------
@@ -43,9 +43,15 @@
 
 ### Small Memory Management Algorithm
 
-The small memory management algorithm is a simple memory allocation algorithm. Initially, it is a large piece of memory. When a memory block needs to be allocated, the matching memory block is segmented from the large memory block, and then this matching free memory block is returned to the heap management system. Each memory block contains data head for management use through which the used block and the free block are linked by a doubly linked list, as shown in the following figure:
+The small memory management algorithm is a simple memory allocation algorithm. Initially, it is a large piece of memory. When a memory block needs to be allocated, the matching memory block is segmented from the large memory block, and then this matching free memory block is returned to the heap management system. Each memory block contains data head for management use through which the used block and the free block are linked by a doubly linked list.
+
+
+
+**Use this implementation before 4.1.0**
+
+As shown in the following figure:
 
 ![Small Memory Management Working Mechanism Diagram](figures/08smem_work.png)
 
 Each memory block (whether it is an allocated memory block or a free memory block) contains a data head, including:
 
@@ -55,7 +61,23 @@
 
 The performance of memory management is mainly reflected in the allocation and release of memory. The small memory management algorithm can be embodied by the following examples.
 
+
+
+**4.1.0 and later use this implementation**
+
+As shown in the following figure:
+
+![](figures/08smem_work4.png)
+
+**Heap Start**: The heap head address stores memory usage information, the heap head address pointer, the heap end address pointer, the minimum heap free address pointer, and the memory size.
+
+Each memory block (whether it is an allocated memory block or a free memory block) contains a data head, including:
+
+**pool_ptr**: Small memory object address. If the last bit of the memory block is 1, it is used. If the last bit of the memory block is 0, it is not used. When used, the structure members of the small memory algorithm can be quickly obtained by calc.
+
+
+
 As shown in the following figure, the free list pointer lfree initially points to a 32-byte block of memory. When the user thread wants to allocate a 64-byte memory block, since the memory block pointed to by this lfree pointer is only 32 bytes and does not meet the requirements, the memory manager will continue to search for the next memory block.  When the next memory block with 128 bytes is found, it meets the requirements of the allocation. Because this memory block is large, the allocator will split the memory block, and the remaining memory block (52 bytes) will remain in the lfree linked list, as shown in the following table which is after 64 bytes is allocated.
 
 ![Small Memory Management Algorithm Linked List Structure Diagram 1](figures/08smem_work2.png)
 
@@ -67,7 +89,7 @@
 
 ### Slab Management Algorithm
 
 RT-Thread's slab allocator is an optimized memory allocation algorithm for embedded systems based on the slab allocator implemented by DragonFly BSD founder Matthew Dillon. The most primitive slab algorithm is Jeff Bonwick's efficient kernel memory allocation algorithm introduced for the Solaris operating system.
 
 RT-Thread's slab allocator implementation mainly removes the object construction and destruction process, and only retains the pure buffered memory pool algorithm. The slab allocator is divided into multiple zones according to the size of the object which can also be seen as having a memory pool for each type of object, as shown in the following figure:
 
@@ -89,9 +111,9 @@
 
 ### memheap Management Algorithm
 
 The memheap management algorithm is suitable for systems with multiple memory heaps that are not contiguous. Using memheap memory management can simplify the use of multiple memory heaps in the system: when there are multiple memory heaps in the system, the user only needs to initialize multiple needed memheaps during system initialization and turn on the memheap function to attach multiple memheaps (addresses can be discontinuous) for the system's heap allocation.
 
 >The original heap function will be turned off after memheap is turned on. Both can only be selected by turning RT_USING_MEMHEAP_AS_HEAP on or off.
 
 The working mechanism of memheap is shown in the figure below. First, add multiple blocks of memory to the memheap_item linked list to attach. The allocation of a memory block starts with allocating memory from default memory heap. When it can not be allocated, memheap_item linked list is looked up, and an attempt is made to allocate a memory block from another memory heap. This process is opaque to the user, who only sees one memory heap.
 
@@ -129,12 +151,12 @@
 
 |**Parameters**  |**Description**          |
 |------------|--------------------|
 | memheap    | memheap control block |
 | name       | The name of the memory heap |
 | start_addr | Heap memory area start address |
 | size       | Heap memory size |
 |**Return**  | ——                 |
 | RT_EOK     | Successful       |
 
 ### Memory Heap Management
 
@@ -180,7 +202,7 @@
 Re-allocating the size of the memory block (increase or decrease) based on the allocated memory block can be done through the following function interface:
 
 ```c
 void *rt_realloc(void *rmem, rt_size_t newsize);
 ```
 
 When the memory block is re-allocated, the original memory block data remains the same (in the case of reduction, the subsequent data is automatically truncated). The following table describes the input parameters and return values for this function:
@@ -219,7 +241,7 @@
 When allocating memory blocks, user can set a hook function. The function interface called is as follows:
 
 ```c
 void rt_malloc_sethook(void (*hook)(void *ptr, rt_size_t size));
 ```
 
 The hook function set will callback after the memory allocation. During the callback, the allocated memory block address and size are passed as input parameters. The following table describes the input parameters for this function:
@@ -632,8 +654,8 @@
 - RT -     Thread Operating System
  / | \     3.1.0 build Aug 24 2018
  2006 - 2018 Copyright by rt-thread team
 msh >mempool_sample
 msh >allocate No.0
 allocate No.1
 allocate No.2
 allocate No.3

examples/utest/testcases/kernel/mem_tc.c

@@ -15,9 +15,6 @@
 struct rt_small_mem_item
 {
     rt_ubase_t              pool_ptr;         /**< small memory object addr */
-#ifdef ARCH_CPU_64BIT
-    rt_uint32_t             resv;
-#endif /* ARCH_CPU_64BIT */
     rt_size_t               next;             /**< next free item */
     rt_size_t               prev;             /**< prev free item */
 #ifdef RT_USING_MEMTRACE

src/mem.c

@@ -59,9 +59,6 @@
 struct rt_small_mem_item
 {
     rt_ubase_t              pool_ptr;         /**< small memory object addr */
-#ifdef ARCH_CPU_64BIT
-    rt_uint32_t             resv;
-#endif /* ARCH_CPU_64BIT */
     rt_size_t               next;             /**< next free item */
     rt_size_t               prev;             /**< prev free item */
 #ifdef RT_USING_MEMTRACE
@@ -85,8 +82,6 @@ struct rt_small_mem
     rt_size_t                   mem_size_aligned;       /**< aligned memory size */
 };
 
-#define HEAP_MAGIC 0x1ea0
-
 #define MIN_SIZE (sizeof(rt_ubase_t) + sizeof(rt_size_t) + sizeof(rt_size_t))
 
 #define MEM_MASK ((~(rt_size_t)0) - 1)