linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Nazarewicz" <mina86@mina86.com>
To: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org, linux-mm@kvack.org,
	linaro-mm-sig@lists.linaro.org,
	Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>,
	Russell King <linux@arm.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Daniel Walker <dwalker@codeaurora.org>,
	Mel Gorman <mel@csn.ul.ie>, Arnd Bergmann <arnd@arndb.de>,
	Jesse Barker <jesse.barker@linaro.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Shariq Hasnain <shariq.hasnain@linaro.org>,
	Chunsang Jeong <chunsang.jeong@linaro.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>
Subject: Re: [PATCH] mm: cma: hack/workaround for some allocation issues
Date: Fri, 25 Nov 2011 22:08:16 +0100	[thread overview]
Message-ID: <op.v5isz2nh3l0zgt@mpn-glaptop> (raw)
In-Reply-To: <1322239387-31394-1-git-send-email-m.szyprowski@samsung.com>

On Fri, 25 Nov 2011 17:43:07 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> This is a quick and dirty patch and hack to solve some memory allocation
> issues that appeared at CMA v17 after switching migration code from
> hotplug to memory compaction. Especially the issue with watermark
> adjustment need a real fix instead of disabling the code.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>
> Hello,
>
> This patch fixes the issues that have been reported recently. It should
> be considered only as a temporary solution until a new version of CMA
> patches is ready.
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
> ---
>  mm/compaction.c |    5 ++++-
>  mm/page_alloc.c |   12 +++++++++---
>  2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 3e07341..41976f8 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -79,8 +79,9 @@ isolate_freepages_range(struct zone *zone,
>  skip:
>  			if (freelist)
>  				goto next;
> +failed:
>  			for (; start < pfn; ++start)
> -				__free_page(pfn_to_page(pfn));
> +				__free_page(pfn_to_page(start));
>  			return 0;
>  		}

Yeah, my mistake, sorry about that. ;)


> @@ -91,6 +92,8 @@ skip:
>  			struct page *p = page;
>  			for (i = isolated; i; --i, ++p)
>  				list_add(&p->lru, freelist);
> +		} else if (!isolated) {
> +			goto failed;
>  		}
> next:
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 714b1c1..b4a46c7 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1303,12 +1303,12 @@ int split_free_page(struct page *page)
> 	zone = page_zone(page);
>  	order = page_order(page);
> -
> +#if 0
>  	/* Obey watermarks as if the page was being allocated */
>  	watermark = low_wmark_pages(zone) + (1 << order);
>  	if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
>  		return 0;
> -
> +#endif
>  	/* Remove page from free list */
>  	list_del(&page->lru);
>  	zone->free_area[order].nr_free--;

Come to think of it, this watermark check seem a little meaningless in case of
CMA.  With CMA the pages that we are splitting here have migrate type ISOLATE
so they aren't “free” at all.  Buddy will never use them for allocation.  That
means that we don't really allocate any pages, we just want to split them into
order-0 pages.

Also, if we bail out now, it's a huge waste of time and efforts.

So, if the watermarks need to be checked, they should somewhere before we do
migration and stuff.  This may be due to my ignorance, but I don't know whether
we really need the watermark check if we decide to use plain alloc_page() as
allocator for migrate_pages() rather then compaction_alloc().

> @@ -5734,6 +5734,12 @@ static unsigned long pfn_align_to_maxpage_up(unsigned long pfn)
>  	return ALIGN(pfn, MAX_ORDER_NR_PAGES);
>  }
>+static struct page *
> +cma_migrate_alloc(struct page *page, unsigned long private, int **x)
> +{
> +	return alloc_page(GFP_HIGHUSER_MOVABLE);
> +}
> +
>  static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
>  {
>  	/* This function is based on compact_zone() from compaction.c. */
> @@ -5801,7 +5807,7 @@ static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
>  		}
> 		/* Try to migrate. */
> -		ret = migrate_pages(&cc.migratepages, compaction_alloc,
> +		ret = migrate_pages(&cc.migratepages, cma_migrate_alloc,
>  				    (unsigned long)&cc, false, cc.sync);
> 		/* Migrated all of them? Great! */

Yep, that makes sense to me.  compaction_alloc() takes only free pages (ie. pages
 from buddy system) from given zone.  This means that no pages get discarded or
swapped to disk.  This makes sense for compaction since it's opportunistic in its
nature.  We, however, want pages to be discarded/swapped if that's the only way of
getting pages to migrate to.

Of course, with this change the “(unsigneg long)&cc” part can be safely replaced
with “NULL” and “cc.nr_freepages -= release_freepages(&cc.freepages);” at the end
of the function (not visible in this patch) with the next line removed.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2011-11-25 21:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-18 16:43 [PATCHv17 0/11] Contiguous Memory Allocator Marek Szyprowski
2011-11-18 16:43 ` [PATCH 01/11] mm: page_alloc: handle MIGRATE_ISOLATE in free_pcppages_bulk() Marek Szyprowski
2011-12-12 13:42   ` Mel Gorman
2011-12-12 14:23     ` Michal Nazarewicz
2011-12-12 14:42       ` Mel Gorman
2011-11-18 16:43 ` [PATCH 02/11] mm: compaction: introduce isolate_{free,migrate}pages_range() Marek Szyprowski
2011-12-12 14:07   ` Mel Gorman
2011-12-12 15:22     ` Michal Nazarewicz
2011-12-12 16:30       ` Mel Gorman
2011-12-12 16:46         ` Michal Nazarewicz
2011-12-12 17:20           ` Mel Gorman
2011-11-18 16:43 ` [PATCH 03/11] mm: mmzone: introduce zone_pfn_same_memmap() Marek Szyprowski
2011-12-12 14:19   ` Mel Gorman
2011-12-12 14:35     ` Michal Nazarewicz
2011-12-12 14:40       ` Mel Gorman
2011-12-12 14:51         ` Michal Nazarewicz
2011-12-12 15:51           ` Mel Gorman
2011-11-18 16:43 ` [PATCH 04/11] mm: compaction: export some of the functions Marek Szyprowski
2011-12-12 14:29   ` Mel Gorman
2011-12-12 14:41     ` Michal Nazarewicz
2011-12-12 15:40       ` Mel Gorman
2011-12-12 15:46         ` Michal Nazarewicz
2011-12-12 16:22         ` Arnd Bergmann
2011-11-18 16:43 ` [PATCH 05/11] mm: page_alloc: introduce alloc_contig_range() Marek Szyprowski
2011-11-18 16:43 ` [PATCH 06/11] mm: mmzone: MIGRATE_CMA migration type added Marek Szyprowski
2011-11-18 16:43 ` [PATCH 07/11] mm: page_isolation: MIGRATE_CMA isolation functions added Marek Szyprowski
2011-11-18 16:43 ` [PATCH 08/11] drivers: add Contiguous Memory Allocator Marek Szyprowski
2011-11-18 16:43 ` [PATCH 09/11] X86: integrate CMA with DMA-mapping subsystem Marek Szyprowski
2011-11-18 16:43 ` [PATCH 10/11] ARM: " Marek Szyprowski
2011-11-18 16:43 ` [PATCH 11/11] ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device Marek Szyprowski
2011-11-18 21:20 ` [Linaro-mm-sig] [PATCHv17 0/11] Contiguous Memory Allocator sandeep patil
2011-11-18 21:26   ` Michal Nazarewicz
2011-11-18 23:30     ` sandeep patil
2011-11-19 18:09       ` Michal Nazarewicz
2011-11-25 16:43 ` [PATCH] mm: cma: hack/workaround for some allocation issues Marek Szyprowski
2011-11-25 21:08   ` Michal Nazarewicz [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=op.v5isz2nh3l0zgt@mpn-glaptop \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=chunsang.jeong@linaro.org \
    --cc=corbet@lwn.net \
    --cc=dave@linux.vnet.ibm.com \
    --cc=dwalker@codeaurora.org \
    --cc=jesse.barker@linaro.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=mel@csn.ul.ie \
    --cc=shariq.hasnain@linaro.org \
    /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