All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	mgorman@techsingularity.net, 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 v6 3/6] mm/cma: populate ZONE_CMA
Date: Wed, 26 Oct 2016 09:27:33 +0200	[thread overview]
Message-ID: <49fde512-15dd-33dc-2120-a6ac1491a165@suse.cz> (raw)
In-Reply-To: <20161026043123.GA2901@js1304-P5Q-DELUXE>

On 10/26/2016 06:31 AM, Joonsoo Kim wrote:
> Hello,
>
> Here comes fixed one.
>
> ----------->8------------
> From 93fb05a83d74f9e2c8caebc2fa6d1a8807c9ffb6 Mon Sep 17 00:00:00 2001
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Date: Thu, 24 Mar 2016 22:29:10 +0900
> Subject: [PATCH] mm/cma: populate ZONE_CMA
>
> Until now, reserved pages for CMA are managed in the ordinary zones
> where page's pfn are belong to. This approach has numorous problems
> and fixing them isn't easy. (It is mentioned on previous patch.)
> To fix this situation, ZONE_CMA is introduced in previous patch, but,
> not yet populated. This patch implement population of ZONE_CMA
> by stealing reserved pages from the ordinary zones.
>
> Unlike previous implementation that kernel allocation request with
> __GFP_MOVABLE could be serviced from CMA region, allocation request only
> with GFP_HIGHUSER_MOVABLE can be serviced from CMA region in the new
> approach. This is an inevitable design decision to use the zone
> implementation because ZONE_CMA could contain highmem. Due to this
> decision, ZONE_CMA will work like as ZONE_HIGHMEM or ZONE_MOVABLE.
>
> I don't think it would be a problem because most of file cache pages
> and anonymous pages are requested with GFP_HIGHUSER_MOVABLE. It could
> be proved by the fact that there are many systems with ZONE_HIGHMEM and
> they work fine. Notable disadvantage is that we cannot use these pages
> for blockdev file cache page, because it usually has __GFP_MOVABLE but
> not __GFP_HIGHMEM and __GFP_USER. But, in this case, there is pros and
> cons. In my experience, blockdev file cache pages are one of the top
> reason that causes cma_alloc() to fail temporarily. So, we can get more
> guarantee of cma_alloc() success by discarding that case.
>
> Implementation itself is very easy to understand. Steal when cma area is
> initialized and recalculate various per zone stat/threshold.
>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

Acked-by: Vlastimil Babka <vbabka@suse.cz>

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	mgorman@techsingularity.net, 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 v6 3/6] mm/cma: populate ZONE_CMA
Date: Wed, 26 Oct 2016 09:27:33 +0200	[thread overview]
Message-ID: <49fde512-15dd-33dc-2120-a6ac1491a165@suse.cz> (raw)
In-Reply-To: <20161026043123.GA2901@js1304-P5Q-DELUXE>

On 10/26/2016 06:31 AM, Joonsoo Kim wrote:
> Hello,
>
> Here comes fixed one.
>
> ----------->8------------
> From 93fb05a83d74f9e2c8caebc2fa6d1a8807c9ffb6 Mon Sep 17 00:00:00 2001
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Date: Thu, 24 Mar 2016 22:29:10 +0900
> Subject: [PATCH] mm/cma: populate ZONE_CMA
>
> Until now, reserved pages for CMA are managed in the ordinary zones
> where page's pfn are belong to. This approach has numorous problems
> and fixing them isn't easy. (It is mentioned on previous patch.)
> To fix this situation, ZONE_CMA is introduced in previous patch, but,
> not yet populated. This patch implement population of ZONE_CMA
> by stealing reserved pages from the ordinary zones.
>
> Unlike previous implementation that kernel allocation request with
> __GFP_MOVABLE could be serviced from CMA region, allocation request only
> with GFP_HIGHUSER_MOVABLE can be serviced from CMA region in the new
> approach. This is an inevitable design decision to use the zone
> implementation because ZONE_CMA could contain highmem. Due to this
> decision, ZONE_CMA will work like as ZONE_HIGHMEM or ZONE_MOVABLE.
>
> I don't think it would be a problem because most of file cache pages
> and anonymous pages are requested with GFP_HIGHUSER_MOVABLE. It could
> be proved by the fact that there are many systems with ZONE_HIGHMEM and
> they work fine. Notable disadvantage is that we cannot use these pages
> for blockdev file cache page, because it usually has __GFP_MOVABLE but
> not __GFP_HIGHMEM and __GFP_USER. But, in this case, there is pros and
> cons. In my experience, blockdev file cache pages are one of the top
> reason that causes cma_alloc() to fail temporarily. So, we can get more
> guarantee of cma_alloc() success by discarding that case.
>
> Implementation itself is very easy to understand. Steal when cma area is
> initialized and recalculate various per zone stat/threshold.
>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

Acked-by: Vlastimil Babka <vbabka@suse.cz>

--
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-10-26  7:27 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-14  3:03 [PATCH v6 0/6] Introduce ZONE_CMA js1304
2016-10-14  3:03 ` js1304
2016-10-14  3:03 ` [PATCH v6 1/6] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request js1304
2016-10-14  3:03   ` js1304
2016-10-14  3:03 ` [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA js1304
2016-10-14  3:03   ` js1304
2016-11-01  7:58   ` Chen Feng
2016-11-01  7:58     ` Chen Feng
2016-11-07  6:15     ` Joonsoo Kim
2016-11-07  6:15       ` Joonsoo Kim
2016-11-07  7:08       ` Chen Feng
2016-11-07  7:08         ` Chen Feng
2016-11-07  7:27         ` Joonsoo Kim
2016-11-07  7:27           ` Joonsoo Kim
2016-11-07  7:44           ` Chen Feng
2016-11-07  7:44             ` Chen Feng
2016-11-07  7:46             ` Chen Feng
2016-11-07  7:46               ` Chen Feng
2016-11-08  3:59               ` Joonsoo Kim
2016-11-08  3:59                 ` Joonsoo Kim
2016-11-08  6:59                 ` Chen Feng
2016-11-08  6:59                   ` Chen Feng
2016-11-11  6:38                   ` Joonsoo Kim
2016-11-11  6:38                     ` Joonsoo Kim
2016-10-14  3:03 ` [PATCH v6 3/6] mm/cma: populate ZONE_CMA js1304
2016-10-14  3:03   ` js1304
2016-10-18  7:42   ` Vlastimil Babka
2016-10-18  7:42     ` Vlastimil Babka
2016-10-18  8:27     ` Joonsoo Kim
2016-10-18  8:27       ` Joonsoo Kim
2016-10-26  4:31       ` Joonsoo Kim
2016-10-26  4:31         ` Joonsoo Kim
2016-10-26  7:27         ` Vlastimil Babka [this message]
2016-10-26  7:27           ` Vlastimil Babka
2016-10-14  3:03 ` [PATCH v6 4/6] mm/cma: remove ALLOC_CMA js1304
2016-10-14  3:03   ` js1304
2016-10-14  3:03 ` [PATCH v6 5/6] mm/cma: remove MIGRATE_CMA js1304
2016-10-14  3:03   ` js1304
2016-10-14  3:03 ` [PATCH v6 6/6] mm/cma: remove per zone CMA stat js1304
2016-10-14  3:03   ` js1304
2016-11-07  6:25 ` [PATCH v6 0/6] Introduce ZONE_CMA Joonsoo Kim
2016-11-07  6:25   ` Joonsoo Kim
2016-11-28  7:41   ` Joonsoo Kim
2016-11-28  7:41     ` 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=49fde512-15dd-33dc-2120-a6ac1491a165@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.