linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Laura Abbott <lauraa@codeaurora.org>,
	Minchan Kim <minchan@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Michal Nazarewicz <mina86@mina86.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/6] Introduce ZONE_CMA
Date: Tue, 3 May 2016 10:29:34 +0900	[thread overview]
Message-ID: <20160503012934.GA4060@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <5727069B.5070600@suse.cz>

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2016-05-03  1:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-25  5:21 [PATCH v2 0/6] Introduce ZONE_CMA js1304
2016-04-25  5:21 ` [PATCH v2 1/6] mm/page_alloc: recalculate some of zone threshold when on/offline memory js1304
2016-04-28  7:46   ` Rui Teng
2016-04-29  6:57     ` Joonsoo Kim
2016-04-25  5:21 ` [PATCH v2 2/6] mm/cma: introduce new zone, ZONE_CMA js1304
2016-04-26  9:38   ` Rui Teng
2016-04-29  7:04     ` Joonsoo Kim
2016-04-25  5:21 ` [PATCH v2 3/6] mm/cma: populate ZONE_CMA js1304
2016-04-25  5:21 ` [PATCH v2 4/6] mm/cma: remove ALLOC_CMA js1304
2016-04-25  5:21 ` [PATCH v2 5/6] mm/cma: remove MIGRATE_CMA js1304
2016-04-25  5:21 ` [PATCH v2 6/6] mm/cma: remove per zone CMA stat js1304
2016-04-25  5:36 ` [PATCH v2 0/6] Introduce ZONE_CMA Joonsoo Kim
2016-04-28 10:39   ` Mel Gorman
2016-04-29  6:51     ` Joonsoo Kim
2016-04-29  9:29       ` Mel Gorman
2016-05-02  6:14         ` Joonsoo Kim
2016-05-02  7:49           ` Vlastimil Babka
2016-05-03  1:29             ` Joonsoo Kim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160503012934.GA4060@js1304-P5Q-DELUXE \
    --to=iamjoonsoo.kim@lge.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=lauraa@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mgorman@techsingularity.net \
    --cc=mina86@mina86.com \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).