On Wednesday 06 January 2016 11:35:31 Mark Brown wrote:
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.
I would really expect that memory that is reserved for CMA can still be used for page cache, if not, that sounds like a generic bug in CMA when combined with 64K pages.
To check that this is not a problem with ext4, you could try creating a tmpfs file system (mount -t tmpfs none /tmp) and fill it up with data to see if the CMA memory is being used for that.
- 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.
Agreed.
Arnd