All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 2/3] mm/page_alloc: stop fallback allocation if we already get some freepage
Date: Tue, 12 May 2015 10:36:40 +0200	[thread overview]
Message-ID: <5551BB98.2040703@suse.cz> (raw)
In-Reply-To: <1430119421-13536-2-git-send-email-iamjoonsoo.kim@lge.com>

On 04/27/2015 09:23 AM, Joonsoo Kim wrote:
> Sometimes we try to get more freepages from buddy list than how much
> we really need, in order to refill pcp list. This may speed up following
> allocation request, but, there is a possibility to increase fragmentation
> if we steal freepages from other migratetype buddy list excessively. This
> patch changes this behaviour to stop fallback allocation in order to
> reduce fragmentation if we already get some freepages.
>
> CPU: 8
> RAM: 512 MB with zram swap
> WORKLOAD: kernel build with -j12
> OPTION: page owner is enabled to measure fragmentation
> After finishing the build, check fragmentation by 'cat /proc/pagetypeinfo'
>
> * Before
> Number of blocks type (movable)
> DMA32: 208.4
>
> Number of mixed blocks (movable)
> DMA32: 139
>
> Mixed blocks means that there is one or more allocated page for
> unmovable/reclaimable allocation in movable pageblock. Results shows that
> more than half of movable pageblock is tainted by other migratetype
> allocation.
>
> * After
> Number of blocks type (movable)
> DMA32: 207
>
> Number of mixed blocks (movable)
> DMA32: 111.2
>
> This result shows that non-mixed block increase by 38% in this case.
>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

I agree that keeping fragmentation low is more important than filling up 
the pcplists. Wouldn't expect such large difference though. Are the 
results stable?

> ---
>   mm/page_alloc.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 044f16c..fbe2211 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1292,7 +1292,7 @@ __rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
>    * Call me with the zone->lock already held.
>    */
>   static struct page *__rmqueue(struct zone *zone, unsigned int order,
> -						int migratetype)
> +					int migratetype, int index)
>   {
>   	struct page *page;
>   	bool steal_fallback;
> @@ -1301,6 +1301,10 @@ retry:
>   	page = __rmqueue_smallest(zone, order, migratetype);
>
>   	if (unlikely(!page) && migratetype != MIGRATE_RESERVE) {
> +		/* We already get some freepages so don't do agressive steal */
> +		if (index != 0)
> +			goto out;
> +
>   		if (migratetype == MIGRATE_MOVABLE)
>   			page = __rmqueue_cma_fallback(zone, order);
>
> @@ -1338,7 +1342,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order,
>
>   	spin_lock(&zone->lock);
>   	for (i = 0; i < count; ++i) {
> -		struct page *page = __rmqueue(zone, order, migratetype);
> +		struct page *page = __rmqueue(zone, order, migratetype, i);
>   		if (unlikely(page == NULL))
>   			break;
>
> @@ -1749,7 +1753,7 @@ struct page *buffered_rmqueue(struct zone *preferred_zone,
>   			WARN_ON_ONCE(order > 1);
>   		}
>   		spin_lock_irqsave(&zone->lock, flags);
> -		page = __rmqueue(zone, order, migratetype);
> +		page = __rmqueue(zone, order, migratetype, 0);
>   		spin_unlock(&zone->lock);
>   		if (!page)
>   			goto failed;
>

--
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>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 2/3] mm/page_alloc: stop fallback allocation if we already get some freepage
Date: Tue, 12 May 2015 10:36:40 +0200	[thread overview]
Message-ID: <5551BB98.2040703@suse.cz> (raw)
In-Reply-To: <1430119421-13536-2-git-send-email-iamjoonsoo.kim@lge.com>

On 04/27/2015 09:23 AM, Joonsoo Kim wrote:
> Sometimes we try to get more freepages from buddy list than how much
> we really need, in order to refill pcp list. This may speed up following
> allocation request, but, there is a possibility to increase fragmentation
> if we steal freepages from other migratetype buddy list excessively. This
> patch changes this behaviour to stop fallback allocation in order to
> reduce fragmentation if we already get some freepages.
>
> CPU: 8
> RAM: 512 MB with zram swap
> WORKLOAD: kernel build with -j12
> OPTION: page owner is enabled to measure fragmentation
> After finishing the build, check fragmentation by 'cat /proc/pagetypeinfo'
>
> * Before
> Number of blocks type (movable)
> DMA32: 208.4
>
> Number of mixed blocks (movable)
> DMA32: 139
>
> Mixed blocks means that there is one or more allocated page for
> unmovable/reclaimable allocation in movable pageblock. Results shows that
> more than half of movable pageblock is tainted by other migratetype
> allocation.
>
> * After
> Number of blocks type (movable)
> DMA32: 207
>
> Number of mixed blocks (movable)
> DMA32: 111.2
>
> This result shows that non-mixed block increase by 38% in this case.
>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

I agree that keeping fragmentation low is more important than filling up 
the pcplists. Wouldn't expect such large difference though. Are the 
results stable?

> ---
>   mm/page_alloc.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 044f16c..fbe2211 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1292,7 +1292,7 @@ __rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
>    * Call me with the zone->lock already held.
>    */
>   static struct page *__rmqueue(struct zone *zone, unsigned int order,
> -						int migratetype)
> +					int migratetype, int index)
>   {
>   	struct page *page;
>   	bool steal_fallback;
> @@ -1301,6 +1301,10 @@ retry:
>   	page = __rmqueue_smallest(zone, order, migratetype);
>
>   	if (unlikely(!page) && migratetype != MIGRATE_RESERVE) {
> +		/* We already get some freepages so don't do agressive steal */
> +		if (index != 0)
> +			goto out;
> +
>   		if (migratetype == MIGRATE_MOVABLE)
>   			page = __rmqueue_cma_fallback(zone, order);
>
> @@ -1338,7 +1342,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order,
>
>   	spin_lock(&zone->lock);
>   	for (i = 0; i < count; ++i) {
> -		struct page *page = __rmqueue(zone, order, migratetype);
> +		struct page *page = __rmqueue(zone, order, migratetype, i);
>   		if (unlikely(page == NULL))
>   			break;
>
> @@ -1749,7 +1753,7 @@ struct page *buffered_rmqueue(struct zone *preferred_zone,
>   			WARN_ON_ONCE(order > 1);
>   		}
>   		spin_lock_irqsave(&zone->lock, flags);
> -		page = __rmqueue(zone, order, migratetype);
> +		page = __rmqueue(zone, order, migratetype, 0);
>   		spin_unlock(&zone->lock);
>   		if (!page)
>   			goto failed;
>


  reply	other threads:[~2015-05-12  8:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27  7:23 [PATCH 1/3] mm/page_alloc: don't break highest order freepage if steal Joonsoo Kim
2015-04-27  7:23 ` Joonsoo Kim
2015-04-27  7:23 ` [PATCH 2/3] mm/page_alloc: stop fallback allocation if we already get some freepage Joonsoo Kim
2015-04-27  7:23   ` Joonsoo Kim
2015-05-12  8:36   ` Vlastimil Babka [this message]
2015-05-12  8:36     ` Vlastimil Babka
2015-05-19  7:47     ` Joonsoo Kim
2015-05-19  7:47       ` Joonsoo Kim
2015-04-27  7:23 ` [RFC PATCH 3/3] mm: support active anti-fragmentation algorithm Joonsoo Kim
2015-04-27  7:23   ` Joonsoo Kim
2015-04-27  8:29   ` Mel Gorman
2015-04-27  8:29     ` Mel Gorman
2015-04-28  7:45     ` Joonsoo Kim
2015-04-28  7:45       ` Joonsoo Kim
2015-05-12  9:01       ` Vlastimil Babka
2015-05-12  9:01         ` Vlastimil Babka
2015-05-19  8:04         ` Joonsoo Kim
2015-05-19  8:04           ` Joonsoo Kim
2015-04-27  8:08 ` [PATCH 1/3] mm/page_alloc: don't break highest order freepage if steal Mel Gorman
2015-04-27  8:08   ` Mel Gorman
2015-04-27  8:42   ` Joonsoo Kim
2015-04-27  8:42     ` Joonsoo Kim
2015-05-12  7:57     ` Vlastimil Babka
2015-05-12  7:57       ` Vlastimil Babka
2015-05-12  7:51 ` Vlastimil Babka
2015-05-12  7:51   ` Vlastimil Babka
2015-05-12  7:54   ` Vlastimil Babka
2015-05-12  7:54     ` Vlastimil Babka
2015-05-19  7:44     ` Joonsoo Kim
2015-05-19  7:44       ` Joonsoo Kim
2015-05-19  7:44   ` Joonsoo Kim
2015-05-19  7:44     ` 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=5551BB98.2040703@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --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.