Re: [PATCH v3 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

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.