On 6 January 2016 at 08:27, Pingbo Wen <pingbo.wen@linaro.org> wrote:

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.

It certainly doesn't seem like expected behavior - the CMA allocation is specified as an absolute number and/or a percentage of total memory and this is almost an order of magnitude change in the amount memory allocated which seems unexpected.

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?

It'd certainly be good to understand.