lkml.org 
[lkml]   [2016]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/6] Introduce ZONE_CMA
On Mon, May 02, 2016 at 09:49:47AM +0200, Vlastimil Babka wrote:
> On 05/02/2016 08:14 AM, Joonsoo Kim wrote:
> >>>> >Although it's separate issue, I should mentioned one thing. Related to
> >>>> >I/O pinning issue, ZONE_CMA don't get blockdev allocation request so
> >>>> >I/O pinning problem is much reduced.
> >>>> >
> >>>
> >>>This is not super-clear from the patch. blockdev is using GFP_USER so it
> >>>already should not be classed as MOVABLE. I could easily be looking in
> >>>the wrong place or missed which allocation path sets GFP_MOVABLE.
> >Okay. Please see sb_bread(), sb_getblk(), __getblk() and __bread() in
> >include/linux/buffer_head.h. These are main functions used by blockdev
> >and they uses GFP_MOVABLE. To fix permanent allocation case which is
> >used by mount and cannot be released until umount, Gioh introduces
> >sb_bread_unmovable() but there are many remaining issues that prevent
> >migration at the moment and avoid blockdev allocation from CMA area is
> >preferable approach.
>
> Hm Patch 3/6 describes the lack of blockdev allocations mostly as a
> limitation, although it does mention the possible advantages later.

Because what this patch try to do isn't an optimization. It would be
best to maintain previous behaviour as much as possible but it
doesn't. Therfore, I mentioned it as side-effect of this patch
although it seems to be a good thing to me.

> Anyway, this doesn't have to be specific to ZONE_CMA, right? You
> could just change ALLOC_CMA handling to consider
> GFP_HIGHUSER_MOVABLE instead of just __GFP_MOVABLE. For ZONE_CMA it
> might be inevitable as you describe, but it's already possible to do
> that now, if the advantages are larger than the disadvantages.

I think that it's not easy. Even if we just allow freepages on CMA area
when GFP_HIGHUSER_MOVABLE allocation request comes, compaction could move
__GFP_MOVABLE pages to freepages on CMA pageblock. Allocated page has no
knowledge about requested gfp and compaction just assume that
migration within a single zone is safe. So, compaction would migrate
__GFP_MOVABLE blockdev pages on ordinary pageblock to the page on CMA
pageblock and we can't easily prevent it. I guess it would be marginal
amount but I'm not sure whether it causes some other problems or not.

Thanks.

\
 
 \ /
  Last update: 2016-05-03 03:41    [W:0.055 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site