All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Andrew Morton <akpm@linux-foundation.org>, Gioh Kim <gioh.kim@lge.com>
Cc: "Laura Abbott" <lauraa@codeaurora.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Joonsoo Kim" <js1304@gmail.com>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	이건호 <gunho.lee@lge.com>, "Gi-Oh Kim" <gurugio@gmail.com>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH] [RFC] CMA: clear buffer-head lru before page migration
Date: Tue, 08 Jul 2014 18:46:31 +0200	[thread overview]
Message-ID: <xa1tpphf4x3s.fsf@mina86.com> (raw)
In-Reply-To: <20140707155252.15e81dff6683393ba3590478@linux-foundation.org>

On Mon, Jul 07 2014, Andrew Morton <akpm@linux-foundation.org> wrote:
> What I proposed is that CMA call invalidate_bh_lrus() right at the
> outset.  Something along the lines of
>
> --- a/mm/page_alloc.c~a
> +++ a/mm/page_alloc.c
> @@ -6329,6 +6329,14 @@ int alloc_contig_range(unsigned long sta
>  	};
>  	INIT_LIST_HEAD(&cc.migratepages);
>  
> +#ifdef CONFIG_CMA
> +	/*
> +	 * Comment goes here
> +	 */
> +	if (migratetype == MIGRATE_CMA)
> +		invalidate_bh_lrus();
> +#endif
> +

This seems reasonable, except I think it should go after
start_isolate_page_range call because otherwise there's no guarantee
that someone won't grab those pages back.

Also to avoid the #ifdef perhaps we want this as well:

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 6cbd1b6..2640a55 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -64,10 +64,11 @@ enum {
 };
 
 #ifdef CONFIG_CMA
-#  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#  define __is_migrate_cma(migratetype) ((migratetype) == MIGRATE_CMA)
 #else
-#  define is_migrate_cma(migratetype) false
+#  define __is_migrate_cma(migratetype) false
 #endif
+#define is_migrate_cma(migratetype) unlikely(__is_migrate_cma(migratetype))
 
 #define for_each_migratetype_order(order, type) \
 	for (order = 0; order < MAX_ORDER; order++) \

and then use “if (__is_migrate_cma(migratetype))”.

>  	/*
>  	 * What we do here is we mark all pageblocks in range as
>  	 * MIGRATE_ISOLATE.  Because pageblock and max order pages may
>
>
> - I'd have thought that it would make sense to do this for huge pages
>   as well (MIGRATE_MOVABLE) but nobody really seems to know.
>
> - There's a patch floating around ("Allow increasing the buffer-head
>   per-CPU LRU size") which will double the size of the bh lrus, so this
>   all becomes more important.
>
> - alloc_contig_range() does lru_add_drain_all() and drain_all_pages()
>   *after* performing the allocation.  I can't work out why this is the
>   case and of course it is undocumented.  If this is indeed not a bug
>   then probably the invalidate_bh_lrus() should happen in the same
>   place.

The purpose is to get free non-buddy pages (so pages on PCP lists for
instance) back onto the buddy list.  It's safe to move those calls above
the call to __alloc_contig_migrate_range, but I don't think it will
change anything (except of course the fact that if migration fails,
we'll do the draining for nothing).

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Michal Nazarewicz <mina86@mina86.com>
To: Andrew Morton <akpm@linux-foundation.org>, Gioh Kim <gioh.kim@lge.com>
Cc: "Laura Abbott" <lauraa@codeaurora.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Joonsoo Kim" <js1304@gmail.com>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	이건호 <gunho.lee@lge.com>, "Gi-Oh Kim" <gurugio@gmail.com>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH] [RFC] CMA: clear buffer-head lru before page migration
Date: Tue, 08 Jul 2014 18:46:31 +0200	[thread overview]
Message-ID: <xa1tpphf4x3s.fsf@mina86.com> (raw)
In-Reply-To: <20140707155252.15e81dff6683393ba3590478@linux-foundation.org>

On Mon, Jul 07 2014, Andrew Morton <akpm@linux-foundation.org> wrote:
> What I proposed is that CMA call invalidate_bh_lrus() right at the
> outset.  Something along the lines of
>
> --- a/mm/page_alloc.c~a
> +++ a/mm/page_alloc.c
> @@ -6329,6 +6329,14 @@ int alloc_contig_range(unsigned long sta
>  	};
>  	INIT_LIST_HEAD(&cc.migratepages);
>  
> +#ifdef CONFIG_CMA
> +	/*
> +	 * Comment goes here
> +	 */
> +	if (migratetype == MIGRATE_CMA)
> +		invalidate_bh_lrus();
> +#endif
> +

This seems reasonable, except I think it should go after
start_isolate_page_range call because otherwise there's no guarantee
that someone won't grab those pages back.

Also to avoid the #ifdef perhaps we want this as well:

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 6cbd1b6..2640a55 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -64,10 +64,11 @@ enum {
 };
 
 #ifdef CONFIG_CMA
-#  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#  define __is_migrate_cma(migratetype) ((migratetype) == MIGRATE_CMA)
 #else
-#  define is_migrate_cma(migratetype) false
+#  define __is_migrate_cma(migratetype) false
 #endif
+#define is_migrate_cma(migratetype) unlikely(__is_migrate_cma(migratetype))
 
 #define for_each_migratetype_order(order, type) \
 	for (order = 0; order < MAX_ORDER; order++) \

and then use “if (__is_migrate_cma(migratetype))”.

>  	/*
>  	 * What we do here is we mark all pageblocks in range as
>  	 * MIGRATE_ISOLATE.  Because pageblock and max order pages may
>
>
> - I'd have thought that it would make sense to do this for huge pages
>   as well (MIGRATE_MOVABLE) but nobody really seems to know.
>
> - There's a patch floating around ("Allow increasing the buffer-head
>   per-CPU LRU size") which will double the size of the bh lrus, so this
>   all becomes more important.
>
> - alloc_contig_range() does lru_add_drain_all() and drain_all_pages()
>   *after* performing the allocation.  I can't work out why this is the
>   case and of course it is undocumented.  If this is indeed not a bug
>   then probably the invalidate_bh_lrus() should happen in the same
>   place.

The purpose is to get free non-buddy pages (so pages on PCP lists for
instance) back onto the buddy list.  It's safe to move those calls above
the call to __alloc_contig_migrate_range, but I don't think it will
change anything (except of course the fact that if migration fails,
we'll do the draining for nothing).

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

  parent reply	other threads:[~2014-07-08 16:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04  8:25 [PATCH] [RFC] CMA: clear buffer-head lru before page migration Gioh Kim
2014-07-07 22:52 ` Andrew Morton
2014-07-08  4:44   ` Gioh Kim
2014-07-08  4:48     ` Andrew Morton
2014-07-08 16:46   ` Michal Nazarewicz [this message]
2014-07-08 16:46     ` Michal Nazarewicz
2014-07-14  7:02     ` Joonsoo Kim
2014-07-14  7:02       ` Joonsoo Kim
2014-07-14 15:25       ` Michal Nazarewicz
2014-07-14 20:37       ` Andrew Morton
2014-07-15  6:25         ` Gioh Kim
2014-07-15  6:25           ` Gioh 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=xa1tpphf4x3s.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=gioh.kim@lge.com \
    --cc=gunho.lee@lge.com \
    --cc=gurugio@gmail.com \
    --cc=js1304@gmail.com \
    --cc=lauraa@codeaurora.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.