From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Mel Gorman <mgorman@techsingularity.net>
Cc: 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: Mon, 2 May 2016 09:49:47 +0200 [thread overview]
Message-ID: <5727069B.5070600@suse.cz> (raw)
In-Reply-To: <20160502061423.GA31646@js1304-P5Q-DELUXE>
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.
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.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Mel Gorman <mgorman@techsingularity.net>
Cc: 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: Mon, 2 May 2016 09:49:47 +0200 [thread overview]
Message-ID: <5727069B.5070600@suse.cz> (raw)
In-Reply-To: <20160502061423.GA31646@js1304-P5Q-DELUXE>
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.
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.
next prev parent reply other threads:[~2016-05-02 7:49 UTC|newest]
Thread overview: 36+ 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 ` 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-25 5:21 ` js1304
2016-04-28 7:46 ` Rui Teng
2016-04-28 7:46 ` Rui Teng
2016-04-29 6:57 ` Joonsoo Kim
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-25 5:21 ` js1304
2016-04-26 9:38 ` Rui Teng
2016-04-26 9:38 ` Rui Teng
2016-04-29 7:04 ` Joonsoo Kim
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 ` js1304
2016-04-25 5:21 ` [PATCH v2 4/6] mm/cma: remove ALLOC_CMA js1304
2016-04-25 5:21 ` js1304
2016-04-25 5:21 ` [PATCH v2 5/6] mm/cma: remove MIGRATE_CMA js1304
2016-04-25 5:21 ` js1304
2016-04-25 5:21 ` [PATCH v2 6/6] mm/cma: remove per zone CMA stat js1304
2016-04-25 5:21 ` js1304
2016-04-25 5:36 ` [PATCH v2 0/6] Introduce ZONE_CMA Joonsoo Kim
2016-04-25 5:36 ` Joonsoo Kim
2016-04-28 10:39 ` Mel Gorman
2016-04-28 10:39 ` Mel Gorman
2016-04-29 6:51 ` Joonsoo Kim
2016-04-29 6:51 ` Joonsoo Kim
2016-04-29 9:29 ` Mel Gorman
2016-04-29 9:29 ` Mel Gorman
2016-05-02 6:14 ` Joonsoo Kim
2016-05-02 6:14 ` Joonsoo Kim
2016-05-02 7:49 ` Vlastimil Babka [this message]
2016-05-02 7:49 ` Vlastimil Babka
2016-05-03 1:29 ` Joonsoo Kim
2016-05-03 1:29 ` Joonsoo Kim
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=5727069B.5070600@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.