From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
Rafael Aquini <aquini@redhat.com>,
Christoph Lameter <cl@linux.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/4] mm/migrate: correct return value of migrate_pages()
Date: Mon, 9 Dec 2013 17:42:45 +0900 [thread overview]
Message-ID: <20131209084245.GA27201@lge.com> (raw)
In-Reply-To: <1386355046-jja39cg0-mutt-n-horiguchi@ah.jp.nec.com>
On Fri, Dec 06, 2013 at 01:37:26PM -0500, Naoya Horiguchi wrote:
> On Fri, Dec 06, 2013 at 03:42:16PM +0100, Vlastimil Babka wrote:
> > On 12/06/2013 09:41 AM, Joonsoo Kim wrote:
> > >migrate_pages() should return number of pages not migrated or error code.
> > >When unmap_and_move return -EAGAIN, outer loop is re-execution without
> > >initialising nr_failed. This makes nr_failed over-counted.
> > >
> > >So this patch correct it by initialising nr_failed in outer loop.
> > >
> > >Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > >
> > >diff --git a/mm/migrate.c b/mm/migrate.c
> > >index 3747fcd..1f59ccc 100644
> > >--- a/mm/migrate.c
> > >+++ b/mm/migrate.c
> > >@@ -1102,6 +1102,7 @@ int migrate_pages(struct list_head *from, new_page_t get_new_page,
> > >
> > > for(pass = 0; pass < 10 && retry; pass++) {
> > > retry = 0;
> > >+ nr_failed = 0;
> > >
> > > list_for_each_entry_safe(page, page2, from, lru) {
> > > cond_resched();
> > >
> >
> > If I'm reading the code correctly, unmap_and_move() (and
> > unmap_and_move_huge_page() as well) deletes all pages from the
> > 'from' list, unless it fails with -EAGAIN. So the only pages you see
> > in subsequent passes are those that failed with -EAGAIN and those
> > are not counted as nr_failed. So there shouldn't be over-count, but
> > your patch could result in under-count.
> >
> > Perhaps a comment somewhere would clarify this.
>
> I agree and suggest the one below.
> Joonsoo, feel free to append it to your series:)
>
> Thanks,
> Naoya Horiguchi
> ---
> From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Date: Fri, 6 Dec 2013 13:08:15 -0500
> Subject: [PATCH] migrate: add comment about permanent failure path
>
> Let's add a comment about where the failed page goes to, which makes
> code more readable.
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> ---
> mm/migrate.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 661ff5f66591..c01caafa0a6f 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1118,7 +1118,12 @@ int migrate_pages(struct list_head *from, new_page_t get_new_page,
> nr_succeeded++;
> break;
> default:
> - /* Permanent failure */
> + /*
> + * Permanent failure (-EBUSY, -ENOSYS, etc.):
> + * unlike -EAGAIN case, the failed page is
> + * removed from migration page list and not
> + * retried in the next outer loop.
> + */
> nr_failed++;
> break;
> }
> --
> 1.8.3.1
Hello, Naoya.
When I saw this new comment, I found that unmap_and_move_huge_page()
has a bug. It would not remove the page from the list if
hugepage_migration_support() is false.
I will include your patch into my series and send an additional patch to fix
this problem.
Thanks.
--
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: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
Rafael Aquini <aquini@redhat.com>,
Christoph Lameter <cl@linux.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/4] mm/migrate: correct return value of migrate_pages()
Date: Mon, 9 Dec 2013 17:42:45 +0900 [thread overview]
Message-ID: <20131209084245.GA27201@lge.com> (raw)
In-Reply-To: <1386355046-jja39cg0-mutt-n-horiguchi@ah.jp.nec.com>
On Fri, Dec 06, 2013 at 01:37:26PM -0500, Naoya Horiguchi wrote:
> On Fri, Dec 06, 2013 at 03:42:16PM +0100, Vlastimil Babka wrote:
> > On 12/06/2013 09:41 AM, Joonsoo Kim wrote:
> > >migrate_pages() should return number of pages not migrated or error code.
> > >When unmap_and_move return -EAGAIN, outer loop is re-execution without
> > >initialising nr_failed. This makes nr_failed over-counted.
> > >
> > >So this patch correct it by initialising nr_failed in outer loop.
> > >
> > >Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > >
> > >diff --git a/mm/migrate.c b/mm/migrate.c
> > >index 3747fcd..1f59ccc 100644
> > >--- a/mm/migrate.c
> > >+++ b/mm/migrate.c
> > >@@ -1102,6 +1102,7 @@ int migrate_pages(struct list_head *from, new_page_t get_new_page,
> > >
> > > for(pass = 0; pass < 10 && retry; pass++) {
> > > retry = 0;
> > >+ nr_failed = 0;
> > >
> > > list_for_each_entry_safe(page, page2, from, lru) {
> > > cond_resched();
> > >
> >
> > If I'm reading the code correctly, unmap_and_move() (and
> > unmap_and_move_huge_page() as well) deletes all pages from the
> > 'from' list, unless it fails with -EAGAIN. So the only pages you see
> > in subsequent passes are those that failed with -EAGAIN and those
> > are not counted as nr_failed. So there shouldn't be over-count, but
> > your patch could result in under-count.
> >
> > Perhaps a comment somewhere would clarify this.
>
> I agree and suggest the one below.
> Joonsoo, feel free to append it to your series:)
>
> Thanks,
> Naoya Horiguchi
> ---
> From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Date: Fri, 6 Dec 2013 13:08:15 -0500
> Subject: [PATCH] migrate: add comment about permanent failure path
>
> Let's add a comment about where the failed page goes to, which makes
> code more readable.
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> ---
> mm/migrate.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 661ff5f66591..c01caafa0a6f 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1118,7 +1118,12 @@ int migrate_pages(struct list_head *from, new_page_t get_new_page,
> nr_succeeded++;
> break;
> default:
> - /* Permanent failure */
> + /*
> + * Permanent failure (-EBUSY, -ENOSYS, etc.):
> + * unlike -EAGAIN case, the failed page is
> + * removed from migration page list and not
> + * retried in the next outer loop.
> + */
> nr_failed++;
> break;
> }
> --
> 1.8.3.1
Hello, Naoya.
When I saw this new comment, I found that unmap_and_move_huge_page()
has a bug. It would not remove the page from the list if
hugepage_migration_support() is false.
I will include your patch into my series and send an additional patch to fix
this problem.
Thanks.
next prev parent reply other threads:[~2013-12-09 8:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 8:41 [PATCH 1/4] mm/migrate: correct return value of migrate_pages() Joonsoo Kim
2013-12-06 8:41 ` Joonsoo Kim
2013-12-06 8:41 ` [PATCH 2/4] mm/mempolicy: correct putback method for isolate pages if failed Joonsoo Kim
2013-12-06 8:41 ` Joonsoo Kim
2013-12-06 18:43 ` Naoya Horiguchi
2013-12-06 18:43 ` Naoya Horiguchi
2013-12-06 8:41 ` [PATCH 3/4] mm/migrate: remove putback_lru_pages, fix comment on putback_movable_pages Joonsoo Kim
2013-12-06 8:41 ` Joonsoo Kim
2013-12-06 8:58 ` Zhang Yanfei
2013-12-06 8:58 ` Zhang Yanfei
2013-12-06 11:46 ` Joonsoo Kim
2013-12-06 11:46 ` Joonsoo Kim
2013-12-06 8:41 ` [PATCH 4/4] mm/compaction: respect ignore_skip_hint in update_pageblock_skip Joonsoo Kim
2013-12-06 8:41 ` Joonsoo Kim
2013-12-06 14:20 ` Vlastimil Babka
2013-12-06 14:20 ` Vlastimil Babka
2013-12-06 20:59 ` Naoya Horiguchi
2013-12-06 20:59 ` Naoya Horiguchi
2013-12-06 14:42 ` [PATCH 1/4] mm/migrate: correct return value of migrate_pages() Vlastimil Babka
2013-12-06 14:42 ` Vlastimil Babka
2013-12-06 18:37 ` Naoya Horiguchi
2013-12-06 18:37 ` Naoya Horiguchi
2013-12-06 18:51 ` Christoph Lameter
2013-12-06 18:51 ` Christoph Lameter
2013-12-09 8:42 ` Joonsoo Kim [this message]
2013-12-09 8:42 ` Joonsoo Kim
2013-12-06 14:52 ` Christoph Lameter
2013-12-06 14:52 ` Christoph Lameter
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=20131209084245.GA27201@lge.com \
--to=iamjoonsoo.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=riel@redhat.com \
--cc=vbabka@suse.cz \
/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.