Environment: a 64 - bit centos7.2 (3.10.0-327) or centos7.4 (3.10.0-693), and restart the system, no pressure, also enough physical memory, and then there were more than 10 G,

Phenomenon:
Mmap 4 k pages for each application, apply for 1024 * 1024 consecutive (a total of 4 g), successful, can be seen in the top and/proc/smaps takes up about 4 g physical memory,
Then, for each memory pages, calls munmap, but some munmap failure, 12 (ENOMEM), the error is shown in the top and/proc/smaps, also take up 1.6 G of physical memory,

Question:
Application of time is according to the pages of particle size distribution of success, when release is made to the granularity of page release, why to munmap (memory)?
In addition, if you remove (I % 11==0 | | I %==0 197 | | I % 393==0) this condition, the munmap is not an error, but I didn't across page release,

Code:

 # include & lt; iostream> 
#include  
#include  
#include  
#include  

# define PAGE_SIZE 4096 
# define PAGE_COUNT 1024 * 1024 

Int main () 
{
STD: : string STR. 
Void * * table=new void * [PAGE_COUNT]; 

STD: : cout & lt; <"Begin mmap... "& lt; for (int i=0; iThe table [I]=mmap (NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 1, 0). 
Assert (table [I]!=MAP_FAILED); 
Memset (table [I] 1, PAGE_SIZE); 
} 

STD: : cout & lt; <"Mmap finish. Input any STR and enter to begin munmap... "& lt; STD: : cin & gt;> STR; 
for(int i=0; iIf (I % 11==0 | | I %==0 197 | | I %==0 393) 
continue; 
If (munmap (table [I], PAGE_SIZE)!=0) 
STD: : cout & lt; } 

The delete [] table; 
STD: : cin & gt;> STR; 
return 0; 
} 

CodePudding user response:

In addition, if you remove (I % 11==0 | | I %==0 197 | | I % 393==0) this condition, the munmap is not an error, but the I'm not across the page release ,
What do you mean the red?

===========================================
No memory is available.
ENOMEM
The process 's maximum number of The mappings order have had exceeded. This error can also occur for munmap (), when unmapping a region in the middle of an existing mapping, since This results in two smaller the mappings on either side of the region being unmapped.
ENOMEM
(since The Linux 4.7) in The process 's RLIMIT_DATA limit, described in getrlimit (2), he have had exceeded.

CodePudding user response:

@ bigpillow, you marked as green passage, refers to the mapping from a large area unmapping part of it, leads to the mapping area division, which increases the number of mapping, "and I was not across page release", meaning I every time is 4 k mmap, then munmap this 4 k, so no part in the middle of 4 k pages to munmap (such as munmap 3 k), so, should not lead to the mapping area division, why will quote ENOMEM error?

Also, I found that the Linux kernel version from 3.10.0-4.15.0 run the application, has the problem, is the kernel of the bug?

CodePudding user response:

There is something wrong with the structure in this table, you print it out and have a look

CodePudding user response:

Rewrite into C test, has found the original poster described all the problems, should be the kernel of a robustness problem, estimated that the APP did not consider the application memory, so

CodePudding user response:

Mmap application because it is a continuous, have been merged into one
Through the release can cause to the vm. Max_map_count the