On Tue, Jun 21, 2016 at 10:08:24AM +0800, Chen Feng wrote: > > > On 2016/6/20 14:48, Joonsoo Kim wrote: > > On Fri, Jun 17, 2016 at 03:38:49PM +0800, Chen Feng wrote: > >> Hi Kim & feng, > >> > >> Thanks for the share. In our platform also has the same use case. > >> > >> We only let the alloc with GFP_HIGHUSER_MOVABLE in memory.c to use cma > >> memory. > >> > >> If we add zone_cma, It seems can resolve the cma migrate issue. > >> > >> But when free_hot_cold_page, we need let the cma page goto system directly > >> not the pcp. > >> It can be fail while cma_alloc and cma_release. If we alloc the whole cma > >> pages which > >> declared before. > > > > Hmm...I'm not sure I understand your explanation. So, if I miss > > something, please let me know. We calls drain_all_pages() when > > isolating pageblock and alloc_contig_range() also has one > > drain_all_pages() calls to drain pcp pages. And, after pageblock isolation, > > freed pages belonging to MIGRATE_ISOLATE pageblock will go to the > > buddy directly so there would be no problem you mentioned. Isn't it? > > > Yes, you are right. > > I mean if the we free cma page to pcp-list, it will goto the migrate_movable > list. > > Then the alloc with movable flag can use the cma memory from the list with > buffered_rmqueue. > > But that's not what we want. It will cause the migrate fail if all movable > alloc can use cma memory.
Yes, if you modify current kernel code to allow cma pages only for GFP_HIGHUSER_MOVABLE in memory.c, there are some corner cases and some of cma pages would be allocated for !GFP_HIGHUSER_MOVABLE. One possible site is pcp list as you mentioned and the other site is on compaction. If we uses ZONE_CMA, there is no such problem, because freepages on pcp list on ZONE_CMA are allocated only when GFP_HIGHUSER_MOVABLE requset comes. Thanks.
