Hi,
在 2015年12月31日，22:48，Arnd Bergmann arnd@arndb.de 写道：
So in case of 4K pages, the minimum amount of free memory is 3MB, and almost always there are less than 8 MB free, . This is expected.
In contrast, for the 64KB page case, we never have less than 512MB RAM free, and it's usually between 512 and 520MB, which is very surprising and indicates that there is a bug somewhere, either in the accounting or in the code in mm/page_alloc.c that tries to reserve some RAM for __GFP_HIGH allocations. Can you have a look at that code?
The root cause is that CMA reserved 512M memory in 64K page size, and buddy allocator can not eat those memory. Some guys explain that ext4 filesystem don’t support migration page well, I didn’t dig into it yet. After unset CONFIG_CMA, the free memory can down to very low in 64K page size.
Besides that, I found some weird problems in db410c.
1. there is no ZONE_NORMAL, only ZONE_DMA. I don’t know if there are bad influences, or bug in zone_sizes_init(). I have try to hard code max_dma to 64M in zone_sizes_init(), and it works. 2. 512M CMA memory in 64K page. Is the number normal? As I know, 4K page size only have 64M CMA memory. I have tracked the code, and found that the size passed to cma_declare_contiguous() function is the same as 4K page, but after call ALIGN(), the size increase to 512M. 3. As the test data indicated, CMA memory in 4K page can be consumed, but in 64K page, the result is not the same. A bug here?
Pingbo