CN106168926B - Memory allocation method based on linux buddy system - Google Patents

Abstract

The invention discloses a memory allocation method based on a linux partner system, which is characterized by comprising the steps of distinguishing and marking idle blocks according to memory banks in advance, and preferentially allocating the idle blocks with the same bank number according to the bank number sequence when an application program applies for a memory. The PASR algorithm based on the Bank-active memory allocation strategy effectively reduces the power consumption in the standby state of the system and improves the battery endurance capacity of the mobile equipment.

Description

Memory allocation method based on linux buddy system

technical field

The invention belongs to the technical field of optimization of standby power consumption of embedded devices, in particular to a memory allocation method based on a linux partner system.

Background technique

With the rapid development of smart phones, the contradiction between power consumption and performance that has plagued traditional computers for a long time has become more prominent on smart phones. The speed of computer development. Thanks to the accumulation of technology in traditional computers, the speed of smartphone CPUs has experienced an unusually rapid growth rate in the past few years. Second, the improvement rate of battery manufacturing technology lags far behind the growth rate of electricity demand. Compared with the rapid increase in the computing speed of smartphones, the increase in battery capacity of mobile phones is much slower. This is mainly because the manufacturing process of mobile phone batteries has developed slowly, which is far behind the development speed of integrated circuits used in CPU manufacturing. In addition, due to the essential characteristics of smart phones as mobile devices, the volume of mobile phones is greatly limited. Under the trend of global smart phone manufacturing becoming lighter and thinner, the body of the mobile phone can be described as "every inch is precious", and every piece of space has been utilized to the extreme. It is becoming more and more difficult to rely on the optimization of the structural design of the mobile phone or the improvement of the manufacturing process of the battery to meet the power demand of the fast-growing smart phone. It is urgent to find new means to improve the battery life of the smart phone.

As the memory of a smart phone, its energy consumption accounts for a considerable proportion of the energy consumption of the whole machine, especially in the standby state. Unlike SRAM, DRAM needs to perform self-refresh periodically in order to maintain its saved data from being lost. The current self-refresh strategy of the DRAM is global self-refresh, that is, the entire DRAM is periodically self-refreshed. If a certain part of the DRAM does not store data, then obviously, the periodic self-refresh of this part of the DRAM is unnecessary, which causes a waste of energy consumption. DRAM's partial array self-refresh (PASR) strategy can solve this problem well. PASR means that for the entire DRAM, only the Bank with data is periodically self-refreshed.

However, the physical memory of Linux is relatively discrete now. For the memory requirements of the kernel, the Linux memory management system tends to allocate from memory areas with low physical addresses; while for the memory requirements of user processes, it tends to allocate from memory areas with high physical addresses. And as the process continues to create and die in a reciprocating cycle, the fragmentation problem in the memory is inevitable, which also aggravates the discreteness of the physical memory. The present invention comes from this.

Contents of the invention

The purpose of the present invention is to provide a memory allocation method based on the linux buddy system, which solves the problem that the power consumption of the existing linux buddy system in the prior art is high, and the hard migration and aggregation of a large amount of memory data may cause considerable damage. System overhead, as well as many problems that may affect the stability and security of the system, such as loss of memory data.

In order to solve these problems in the prior art, the technical scheme provided by the invention is as follows:

A method for allocating memory based on a linux buddy system, characterized in that the method includes pre-marking free blocks with memory bank numbers according to different memory banks, and assigning priority to free blocks of the same bank number according to bank numbers when application programs apply for memory step.

In the preferred technical solution, the method forms a free block linked list of different bank numbers of the same free block order after marking the memory bank number, and the order of the free block is 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, the free blocks corresponding to the free block ranks sequentially include 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 and 1024 consecutive free page frames.

In the preferred technical solution, the order of free blocks in the method is divided according to the splitting rules of the linux partner system, and the order of free blocks is 0, 1, 2, 3, 4, 5, 6, 7 in sequence , 8, 9, 10, each free block sequentially contains 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 and 1024 consecutive free page frames.

In the preferred technical solution, when the application program in the method applies for memory, it traverses the free blocks of the same bank number according to the priority order of the free block rank; if a free block of the same rank is found, the traversal is terminated; otherwise, continue according to the bank number Traverse the free blocks of the next bank number, and loop until a free block that meets the requirements is found or the allocation fails and returns.

In the preferred technical solution, when the application program applies for memory in the method, it traverses the free blocks of the same level according to the priority order of bank numbers; if it finds a free block of the same level, then terminates the traversal; otherwise, it continues to traverse the next level The free block, and so on loop until a free block that meets the requirements is found or the allocation fails and returns.

In the preferred technical solution, when the memory is initialized in the method, if the application program requests the memory and cannot find a free block of the same level, the linux buddy system will split into the next bit of the buddy according to the order from large to small If the application program requests memory and still cannot find a free block that meets the requirements, continue to split according to the above method until a free block of the same level is found.

In the preferred technical scheme, if the application releases the memory in the method, it is necessary to judge whether the partner block of the released memory free block is free; if the partner block is a free block, then merge the free block according to the merging rules of the linux partner system; Loop until no merging can be done.

Another object of the present invention is a memory refresh method for linux system equipment, which is characterized in that the method includes when the memory blocks of the entire bank are free blocks, and the linux system equipment is in a deep sleep state, according to the memory part array automatically Refresh the configuration and turn off the refresh of the entire memory bank.

In a preferred technical solution, the method further includes when the linux system device wakes up from the deep sleep state or enters the light sleep state, closing the self-refresh configuration of the memory part array, and re-refreshing the entire memory bank.

According to the division of the Linux partner system, all free page frames are grouped into 11 types of free block linked lists, and each free block linked list contains the sizes of 1, 2, 4, 8, 16, 32, 64, 128, 256, There are 512 and 1024 consecutive free page frames, and the order of the free block list is 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10.

buddy system

The buddy system is at the heart of Linux physical memory management. The buddy system groups all free page frames into 11 block lists, and each block list contains 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, and 1024 consecutive page frames. The maximum request for 1024 page frames corresponds to a contiguous RAM block of size 4MB. The physical address of the first page frame of each block is an integer multiple of the block size. For example, a block size of 16 page frames has a starting address that is a multiple of 16*4096 (which is the size of a regular page).

Suppose you want to request a block of 256 page frames (ie 1MB). The algorithm first checks for a free block in the linked list of 256 page frames. If there is no such block, the algorithm looks for the next larger page block, that is, finds a free block in the linked list of 512 page frames. If there is such a block, the kernel splits the 512 page frame block into two equal parts, half of which is used to satisfy the request, and the other half is inserted into the linked list of 256 page frames. If no free block is found in the block chain list of 512 page frames, continue to find a larger free block—a free block of 1024 page frames. If such a block exists, the kernel divides the 1024 page frame blocks into two equal parts of 512 page frame blocks, inserts one of the 512 page frame blocks into the linked list of 512 page frame blocks, and inserts the other 512 page frame blocks The frame block is further divided into two equal parts of 256 page frame blocks, one is inserted into the linked list of 256 page frame blocks, and the other is used to satisfy the request. If the linked list of 1024 page frames is still empty, the algorithm gives up and signals an error.

The reverse process of the above process is the release process of the page frame block, which is also the origin of the algorithm name. The kernel tries to merge a pair of free buddy blocks of size b into a single block of size 2b. Two blocks that meet the following conditions are called partners: a. The two blocks have the same size, denoted as b; b. Their physical addresses are consecutive; c. The physical address of the first page frame of the first block is Multiples of 2*b*4096. The algorithm is iterative, and if it successfully merges freed blocks, it tries to merge blocks of size 2b to again attempt to form larger blocks.

Divide the physical memory of each memory node (node) into three management zones (zone): ZONE_DMA (0~16M), ZONE_NORMAL (16M~896M), ZONE_HIGHMEM (896M~MAX). By dividing into different management areas, the kernel defines a hierarchy of memory, and when there is a memory request, it first tries to allocate "cheap" memory. Failing that, incrementally tries to allocate "more expensive" memory, depending on access speed and capacity.

High memory (ZONE_HIGHMEM) is the cheapest, because no part of the kernel depends on memory allocated from this memory zone. If the high memory zone is exhausted, there will be no side effects on the kernel, which is why high memory is allocated first. The situation is different for the normal memory domain (ZONE_NORMAL). Many kernel data structures must be kept in this memory domain and cannot be placed in the upper memory domain. So if normal memory is completely exhausted, the kernel will panic. So as long as the memory in the upper memory domain is not exhausted, no memory will be allocated from the normal memory domain. The most expensive is the DMA memory zone (ZONE_DMA), since it is used for data transfer between peripherals and the system. So allocating memory from this memory domain is a last resort.

Each management area is divided into multiple free_areas according to the order of free memory blocks. The C language pseudocode of the memory management area is as follows:

<include/linux/mmzone.h>

struct zone {

...

/*

* Free memory blocks of different sizes

*/

struct free_area[MAX_ORDER];

...

};

struct free_area {

struct list_head free_list[MIGRATE_TYPES];

unsigned long nr_free;

};

It can be seen that each free_area is divided into multiple free_lists according to different migration types (migratetype). nr_free represents the number of all free blocks in free_area. The migratetype is not considered, which will not affect the bank. Therefore, the organizational chart of the Linux buddy system is shown in Figure 1. If a memory domain with 2 page frames is requested, the buddy algorithm first searches for a free block in the free_list linked list of free_area[1], and returns it directly if found; otherwise, go to the free_list linked list of free_area with a larger order according to the algorithm logic Find, break down, allocate until allocation request is satisfied or allocation fails.

Aggregation (Bank-Intensive) memory allocation strategy

Linux's buddy system manages the allocation and release of memory simply and efficiently. The centralized memory allocation strategy of Bank aggregation in the technical solution of the present invention is to allocate the memory blocks in the specified Bank according to requirements when allocating memory by modifying the partner system, so as to achieve the allocation effect of Bank aggregation.

There is no concept of Bank in the structure organization of the existing partner system, so it cannot perceive the existence of Bank, and cannot achieve the memory allocation of Bank aggregation. The bank of the present invention is a logic bank, ie L-bank, and the inside of the SDRAM is a storage array. The retrieval principle of the storage array is the same as that of the table. First specify a row (Row) and then specify a column (Column) to accurately find the required storage unit. This is the basic principle of memory chip addressing. The storage array is a logical bank (Logical Bank, L-Bank for short).

The technical scheme of the present invention modifies the structure organization of the linux partner system, adds a Bank structure, subdivides the free_list, reorganizes the free blocks, and hangs the free blocks into the corresponding bank_free_list according to the Bank numbers of the free blocks. Fig. 2 is the structural organization diagram of the modified linux partner system. For the free memory blocks with the same order, they are hung in the same free_list linked list indiscriminately in the original buddy system; while the modified buddy system hangs them in the same free list according to the different Bank numbers of these free blocks. on a different free_list.

The modified linux buddy system does not delete some data structures involved in the original buddy system structure organization, but only adds some data structures to assist the implementation of the Bank-Intensive memory allocation strategy.

A typical implementation is as follows, adding member bank_free_list to struct free_area, as shown in the following C language pseudocode:

<include/linux/mmzone.h>

struct free_area {

...

/*

* Divide the free blocks in a free_list into multiple bank_free_lists according to the Bank number

*Where NR_BANKS_PASR indicates the number of banks

*/

struct list_head bank_free_list[MIGRATE_TYPES][NR_BANKS_PASR];

...

};

Add the member bank_list to the struct page, as shown in the following C language pseudocode:

<include/linux/mmzone.h>

struct page {

...

/*

*The bank_list field stores pointers to adjacent elements in the bank_free_list linked list,

* That is, the free blocks in bank_free_list are linked through the bank_list field in the struct page

*/

struct list_head bank_list;

...

};

Through the addition of bank_free_list and bank_list, the free blocks in a free_list are divided into multiple bank_free_lists according to the different bank numbers; the bank_list field stores pointers to adjacent elements in the bank_free_list linked list, and each free block in the bank_free_list passes through the struct page The bank_list field is linked. In this way, the bank number is seamlessly inserted into the free block list of the partner system, which can be used as the basis for bank aggregation.

memory allocation strategy

From the perspective of Bank selection, sub-allocation strategies can be divided into various allocation strategies such as allocation in ascending or descending order of Bank numbers, allocation of designated banks, and allocation according to Bank utilization; from the perspective of Bank aggregation degree, sub-allocation strategies can be divided into Order-Bank strategy (conservative strategy) and Bank-Order strategy (radical strategy). The sub-allocation strategies divided from two perspectives can be combined into a complete allocation strategy in two groups.

Combined with Figure 2 to explain the allocation strategy. Assuming that the bank numbers are allocated in ascending order, the Order-Bank strategy and the Bank-Order strategy are combined respectively.

Strategy

Suppose you want to request a free block with 1 page frame, first go to the bank_free_list of free_area[0]->bank[0] to search, if there is a free block that meets the requirements, it will return directly. If not found, go to the bank_free_list of free_area[0]->bank[1] to search, and traverse the bank_free_list of bank[2], bank[3]... in free_area[0] until you find a free block that meets the requirements. If it is not found in free_area[0], then search in free_area[1], free_area[2]..., the search order is the same as in free_area[0], until the request is satisfied or the allocation fails and returns.

Strategy

Suppose you want to request a free block with 1 page frame, first go to the bank_free_list of free_area[0]->bank[0] to search, if there is a free block that meets the requirements, it will return directly. If not found, go to the bank_free_list of free_area[1]->bank[0] to search, and traverse the bank_free_list of bank[0] in free_area[2], free_area[3]... until you find a free block that meets the requirements. If it is not found in the bank[0] of each free_area, then search in the bank[1] of each free_area, the search order is the same as that of bank[1], until the request is satisfied or the allocation fails and returns.

How to use the memory allocation strategy based on bank aggregation in real linux smart devices. The present invention provides an implementation method for optimizing the power consumption of linux smart devices, especially the optimization of memory power consumption. In a specific implementation, the technical solution of the present invention is described by taking an Android smart device as an example.

PASR configuration in standby process

In order to perform PASR control, there must first be idle Banks, and in order to achieve a better energy-saving effect, as many Banks as possible should be idled. According to the physical memory layout of Linux, only by adjusting the discrete memory layout and gathering and migrating memory data, can as many banks as possible be freed, and effective PASR control can be carried out to achieve a better energy-saving effect. In-memory data aggregation and migration is to gather valid data in memory to certain banks to free up as many banks as possible. The most direct way to achieve memory data aggregation and migration is to migrate memory data rigidly to certain banks when the system is about to perform PASR control, and leave the rest of the banks free. However, this kind of hard migration and aggregation of a large amount of memory data may bring a lot of system overhead, and it may also cause memory data loss and many other problems that affect the stability and security of the system.

Aiming at the problem of hard aggregation and migration of memory data, the technical solution of the present invention proposes a Bank-Intensive memory allocation strategy. By modifying the Linux memory management system, this strategy makes it possible to gather memory data in some Banks during the memory allocation stage, which greatly improves the power consumption benefit brought by PASR.

Configuration involves the security of memory data, so how to choose the timing of PASR configuration is particularly important. The creation, running, and death of processes in the system are often accompanied by memory allocation and release, resulting in relatively active memory, which is not conducive to PASR configuration. In the Early_Suspend (light sleep) state of Android, some processes are still running. Only when entering the Suspend (deep sleep) state of standard Linux, all processes except the working process are frozen, and the system will basically not exist at this time. For memory allocation and release operations, the memory state is relatively quiet, and PASR configuration can be performed to stop the refresh operation of some idle banks to reduce memory power consumption during standby. When the system wakes up from the dormant state, the reset configuration of PASR should be performed first, and the refresh operation of the idle bank should be enabled, because the system will often perform a large amount of memory allocation at this time. If the memory allocation falls into the idle bank that has not yet started the refresh operation, Part of the memory data will be lost, and even more serious consequences will be caused.

Timing of configuration

In standard Linux, hibernation is mainly divided into three main steps: (1) freezing the user mode process and kernel mode tasks; (2) calling the suspend callback function of the registered device, and the calling order is according to the registration order when the driver is loaded . (3) Sleeping the core device and putting the CPU into a sleep state to freeze the process means that the kernel sets the state of all processes in the process list to stop, and saves the context of all processes. When these processes are unfrozen, they do not know that they have been frozen, but simply continue to execute. From the above analysis, it can be seen that the setting time of PASR should be selected before the core device enters the sleep state. Similarly, after the core device is awakened, the reset operation of PASR should be performed immediately, and the refresh operation of the idle bank should be enabled. By analyzing the source code of the P6s platform kernel (version number is 3.0.8), the code location where the system enters the dormant state is determined, as shown in the following C language pseudocode:

/*

*File:arch/arm/mach-hi6620/pwrctrl/sleepMgr/pwrctrl_sleep.c

*/

s32_t pwrctrl_deep_sleep(suspend_state_t state)

{

...

pwrctrl_asm_deep_sleep_entry(); //sleep entry function

...

}

The pwrctrl_asm_deep_sleep_entry function is written in assembly language and is the entry point for the system to enter the dormant state completely. Before executing this function, perform PASR setting and close the self-refresh operation of the idle bank; when the system is awakened, return from this function, so it should be followed by this function After that, the PASR reset operation is performed, and the self-refresh operation of the idle Bank is restarted.

PASR setting before system sleep

In the memory allocation strategy of Bank aggregation, the usage of page frames in each Bank is counted in real time. When setting PASR, first identify the idle bank according to the usage of the page frame in each bank, and then close the self-refresh of the idle bank by reading and writing the registers related to the bank's self-refresh. The core operation steps are shown in the following C language pseudocode:

/*

*File:arch/arm/mach-hi6620/pwrctrl/sleepMgr/pwrctrl_sleep.c

*/

static void __iomem *REG_BASE_DDRC_DMC0_VIRT = 0;

int pasr_set_segment(int rank)

{

...

for(i = 0+rank_tmp*8; i<(rank_tmp+1)*8; i++)

{

if(nr_free_pages_per_bank[i]>= 32768) //Determine whether bank[i] is free

{

segment_tmp = i % 8;

segment_tmp = 1<<segment_tmp;

segment |= segment_tmp;

}

}

...

value = (segment<<16) | (0x11<<8) | (rank<<4) | 0x2; // free bank set

...

//Write the idle bank set into the self-refresh control register to close its self-refresh operation

writel(value, \ SOC_MDDRC_DMC_DDRC_CFG_SFC_ADDR(REG_BASE_DDRC_DMC0_VIRT));

...

return 0;

}

When it is judged that there is an idle bank set, write the idle bank set into the self-refresh control register to close its self-refresh operation. The self-refresh control register facilitates the PASR reset after the system wakes up later.

PASR reset after system wake-up

Compared with the PASR setting before hibernation, the PASR reset operation after the system wakes up is simpler, because it only needs to set the self-refresh operation of all Banks to the on state, without having to query in detail the idle banks whose self-refresh operation is turned off. Bank then turns it on, and the operation process is shown in the following C language pseudocode:

/*

*File:arch/arm/mach-hi6620/pwrctrl/sleepMgr/pwrctrl_sleep.c

*/

int pasr_reset_segment(void)

{

...

value = 0x0 | (0x11<<8) | (0x3<<4) | 0x2; //A collection of all banks

...

//Set self-refresh of all banks to on

writel(value, SOC_MDDRC_DMC_DDRC_CFG_SFC_ADDR(REG_BASE_DDRC_DMC0_VIRT));

...

return 0;

}

Call the pasr_set_segment function and pasr_reset_segment function before and after the sleep-wake function pwrctrl_asm_deep_sleep_entry to complete the PASR configuration in the standby process, as shown in the following C language pseudo code:

/*

*File:arch/arm/mach-hi6620/pwrctrl/sleepMgr/pwrctrl_sleep.c

*/

s32_t pwrctrl_deep_sleep(suspend_state_t state)

{

...

pasr_set_segment(0); //Close the self-refresh of the idle bank in rank0

pasr_set_segment(1); //Close the self-refresh of the idle bank in rank1

pwrctrl_asm_deep_sleep_entry();

pasr_reset_segment(); //Enable bank self-refresh

...

}

The method is to close the PASR configuration information, such as clearing the temporary storage information of the self-refresh control register, and then set all banks to the self-refresh state.

Compared with the scheme in the prior art, the advantages of the present invention are:

The present invention is based on a bank-intensive memory allocation strategy, and by modifying the original memory allocation strategy of the Linux partner system, the memory allocation can achieve a better aggregation effect relative to the bank. Through the experimental verification on the multi-party platform, the aggregation effect is quite good. Cooperating with PASR control, the profit of standby power optimization under the P6s platform reaches 23%, which reflects the effectiveness and practicability of the PASR algorithm. In short, the PASR algorithm based on the Bank-Intensive memory allocation strategy effectively reduces the power consumption of the system in standby mode and improves the battery life of mobile devices.

Description of drawings

The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

Figure 1 is an organizational chart of the original Linux buddy system.

Figure 2 is the modified organization chart of the linux partner system.

Figure 3 shows the memory allocation result of the original memory allocation strategy.

Figure 4 is a memory allocation diagram of the bank-order allocation strategy allocated according to the bank utilization rate.

Figure 5 shows the usage of each segment after the system is started and stabilized.

Figure 6 shows the usage of each segment when an application is started.

Figure 7 shows the usage of each segment when multiple applications are started.

Detailed ways

The above solution will be further described below in conjunction with specific embodiments. It should be understood that these examples are used to illustrate the present invention and not to limit the scope of the present invention. The implementation conditions used in the examples can be further adjusted according to the conditions of the specific system, and the unspecified implementation conditions are usually the conditions in routine experiments.

Example

Purpose

The Bank-Intensive memory allocation strategy modifies the Linux partner system and adds a Bank structure on the basis of the original structure organization to achieve a more concentrated memory allocation than the Bank. The purpose of this experiment is to test and verify the memory aggregation effect of this allocation strategy.

experiment platform

Software platform: Windows XP (host) + VMware (virtual machine) + android-x86;

The experimental platform is to install a VMware virtual machine on a Windows XP host machine, and run the android-x86 system in the virtual machine. The test and verification of this strategy has been completed.

The following is a detailed introduction to each part of the experimental platform.

(Host) CPU model is Intel Core2 Quad Q8400, 4G memory, 500G hard disk.

(Virtual machine) It configures 2 processors in the hardware environment of the host machine, each processor has 1 core, 2G memory, and 20G hard disk

Virtual memory specifications, the information is as follows:

DDR size is 2GByte, 2 ranks, each rank has 8 banks, data bit width is 32 bits, internal 4 DIEs, each DIE data bit width is 16 bits, each rank is composed of 2 DIEs, namely two 16bits Spliced into 32bit. Table 1 shows the DRAM address mapping method. The 1-bit rank number and the 3-bit bank number together form 16 Banks.

Table 1 DRAM address mapping method rank row bank column DW number of bits 1 14 3 11 2 Fixed to 2'b00

Android-x86 uses the ics-x86 version, which is based on Android4.0 (Ice Cream Sandwich).

experimental method

The content of the test is the memory allocation during the whole process of system startup, that is, the memory allocation required for the system itself to run. After the system starts up and runs smoothly, insert the memory statistics module to make statistics on memory allocation. When a module is unloaded, a statistical structure of the memory allocation is output on the terminal.

Experimental Results and Analysis

The various allocation strategies mentioned in the allocation strategy were tested, and the bank-order allocation strategy that is allocated according to the bank utilization rate was taken as an example to analyze the experimental results.

bank_no in FIG. 3 and FIG. 4 indicates the bank number, nr_alloc_pages indicates the number of allocated page frames in the bank, and nr_free_pages indicates the number of free page frames in the bank. total_nr_free_pages and total_nr_alloc_pages respectively represent the number of free page frames and the number of allocated page frames in the entire system. Comparing Figure 3 and Figure 4, it can be seen that the original memory allocation strategy does not perceive the existence of Bank, and memory allocation is random and discrete compared to Bank; while Bank-Order allocation based on Bank utilization In the strategy, Bank9~Bank15 are basically freed, and 40% of the page frames are allocated to Bank8 (26203 / 64086), and the aggregation effect is very obvious.

Aggregation effect and power consumption benefit verification under the platform

Due to the limitation of the platform, the early part of the experiment was carried out in a virtual environment. In this section, the PASR algorithm is transplanted to the P6s platform for experimental testing in a real environment, including the verification of the aggregation effect of the Bank-Intensive memory allocation strategy and the verification of the power consumption benefits it brings.

The platform is equipped with a HiSilicon Kirin910 quad-core processor with a main frequency of 1.6G HZ and a RAM capacity of 2GB. The address mapping mode of memory DRAM is shown in Table 1.

After checking the chip manual and discussion and analysis, the PASR controllable granularity of DRAM under the P6s platform is segment (the first 3 digits in the row) or bank. In order to ensure that the continuous memory block in the controllable granularity unit is large enough to satisfy the memory allocation request as much as possible, this PASR algorithm selects segment as the basic control unit of PASR. The effect of the Bank-Intensive memory allocation strategy (allocated according to the segment utilization rate, and the segment with high utilization rate is allocated first) is tested respectively in the following three application scenarios: after the system is started, when an application is started, and when multiple applications are started.

Figure 5 shows the usage of each segment after the system is started and stabilized. It can be seen that segment2, segment7~segment12 are completely free. Figure 6 shows the usage of each segment when an application is started after the system is stable. It can be seen that the memory allocation is concentrated on segment7 and segment8, and segment2, segment9~segment12 are still completely free.

Figure 7 shows the usage of each segment after continuing to start the application. It can be seen that the memory allocation continues to concentrate on segment7 and segment8, among which segment7 is completely allocated, and segment2, segment9~segment12 are still completely free.

The above experimental data shows that the Bank-Intensive memory allocation strategy also exhibits excellent aggregation and allocation effects on the P6s platform, making full use of the occupied segments to free up more segments for PASR control. Combined with the PASR configuration in the Android standby process, turn off the self-refresh of the idle segment when the system enters the standby state, and test the power consumption gain. The result: in the original standby state, the average current of the system is 2.60mA, and the memory allocation based on Bank-Intensive is enabled After the PASR control of the strategy, the average current drops to 2.00mA, and the gain reaches 23%. Analyzing the reason, it is not difficult to find that after the system starts smoothly, 7 segments are completely idle (as shown in Figure 5). PASR control disables the self-refresh operation of these 7 idle segments by configuring related registers, thus bringing the above-mentioned power gain.

The above-mentioned embodiments are only to illustrate the technical conception and characteristics of the present invention. The purpose is to enable those familiar with this technology to understand the content of the present invention and implement it accordingly, and not to limit the protection scope of the present invention. All equivalent changes or modifications made according to the spirit of the present invention shall fall within the protection scope of the present invention.

Claims (6)

1. The memory allocation method based on the linux partner system is characterized by comprising the steps of marking the free blocks with memory bank numbers according to different memory banks in advance, and preferentially allocating the free blocks with the same bank number according to the bank numbers when an application program applies for a memory; the method comprises the steps of marking memory bank numbers to form a free block linked list of different bank numbers of the same free block level (order), wherein the free block level is 0, 1,2, 3, 4, 5, 6, 7, 8, 9 and 10 in sequence, and the free blocks of the corresponding free block level sequentially comprise continuous free page frames with the sizes of 1,2,4,8, 16, 32, 64, 128, 256, 512 and 1024.

2. The memory allocation method according to claim 1, wherein the idle block levels (orders) in the method are divided according to a split rule of a linux partner system, the idle block levels are sequentially 0, 1,2, 3, 4, 5, 6, 7, 8, 9, 10, and each idle block sequentially contains 1,2,4,8, 16, 32, 64, 128, 256, 512, and 1024 consecutive idle page frames.

3. The memory allocation method according to claim 1, wherein when an application program applies for memory, the method traverses idle blocks with the same bank number according to the priority order of idle block levels; if the idle blocks with the same level are found, the traversal is terminated; otherwise, traversing the idle block of the next bank number according to the bank number, and circulating until the idle block meeting the requirement is found or the allocation fails to return.

4. The memory allocation method according to claim 1, wherein when an application program applies for memory, the method traverses idle blocks of the same level according to the priority order of bank numbers; if the idle blocks with the same level are found, the traversal is terminated; otherwise, continuing to traverse the idle block of the next level, and circulating until the idle block meeting the requirement is found or the allocation fails to return.

5. The memory allocation method according to claim 1, wherein when the memory is initialized in the method, if the application program requests the memory to find the idle blocks with the same level, the linux partner system splits the idle blocks into the idle blocks with the next level of the partner according to the order from the higher level to the lower level; if the application program requests the memory to still find the idle blocks meeting the requirement, the method continues to split until the idle blocks with the same level are found.

6. The memory allocation method according to claim 1, wherein if the application releases the memory, it is determined whether the partner block of the released memory free block is free; if the partner block is an idle block, the idle block is merged according to the merging rule of the linux partner system; this is looped until no merging can take place.

Images