All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Michal Nazarewicz <mina86@mina86.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 2/2] mm: support MIGRATE_DISCARD
Date: Thu, 6 Sep 2012 14:31:12 +0900	[thread overview]
Message-ID: <20120906053112.GA16231@bbox> (raw)
In-Reply-To: <20120905105611.GI11266@suse.de>

Hi Mel,

On Wed, Sep 05, 2012 at 11:56:11AM +0100, Mel Gorman wrote:
> On Wed, Sep 05, 2012 at 05:11:13PM +0900, Minchan Kim wrote:
> > This patch introudes MIGRATE_DISCARD mode in migration.
> > It drops *clean cache pages* instead of migration so that
> > migration latency could be reduced by avoiding (memcpy + page remapping).
> > It's useful for CMA because latency of migration is very important rather
> > than eviction of background processes's workingset. In addition, it needs
> > less free pages for migration targets so it could avoid memory reclaiming
> > to get free pages, which is another factor increase latency.
> > 
> 
> Bah, this was released while I was reviewing the older version. I did
> not read this one as closely but I see the enum problems have gone away
> at least. I'd still prefer if CMA had an additional helper to discard
> some pages with shrink_page_list() and migrate the remaining pages with
> migrate_pages(). That would remove the need to add a MIGRATE_DISCARD
> migrate mode at all.

I am not convinced with your point. What's the benefit on separating
reclaim and migration? For just removing MIGRATE_DISCARD mode?
I don't think it's not bad because my implementation is very simple(maybe
it's much simpler than separating reclaim and migration) and
could be used by others like memory-hotplug in future.
If you're not strong against with me, I would like to insist on my implementation.

> 
> -- 
> Mel Gorman
> SUSE Labs
> 
> --
> 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>

-- 
Kind regards,
Minchan Kim

--
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: Minchan Kim <minchan@kernel.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Michal Nazarewicz <mina86@mina86.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 2/2] mm: support MIGRATE_DISCARD
Date: Thu, 6 Sep 2012 14:31:12 +0900	[thread overview]
Message-ID: <20120906053112.GA16231@bbox> (raw)
In-Reply-To: <20120905105611.GI11266@suse.de>

Hi Mel,

On Wed, Sep 05, 2012 at 11:56:11AM +0100, Mel Gorman wrote:
> On Wed, Sep 05, 2012 at 05:11:13PM +0900, Minchan Kim wrote:
> > This patch introudes MIGRATE_DISCARD mode in migration.
> > It drops *clean cache pages* instead of migration so that
> > migration latency could be reduced by avoiding (memcpy + page remapping).
> > It's useful for CMA because latency of migration is very important rather
> > than eviction of background processes's workingset. In addition, it needs
> > less free pages for migration targets so it could avoid memory reclaiming
> > to get free pages, which is another factor increase latency.
> > 
> 
> Bah, this was released while I was reviewing the older version. I did
> not read this one as closely but I see the enum problems have gone away
> at least. I'd still prefer if CMA had an additional helper to discard
> some pages with shrink_page_list() and migrate the remaining pages with
> migrate_pages(). That would remove the need to add a MIGRATE_DISCARD
> migrate mode at all.

I am not convinced with your point. What's the benefit on separating
reclaim and migration? For just removing MIGRATE_DISCARD mode?
I don't think it's not bad because my implementation is very simple(maybe
it's much simpler than separating reclaim and migration) and
could be used by others like memory-hotplug in future.
If you're not strong against with me, I would like to insist on my implementation.

> 
> -- 
> Mel Gorman
> SUSE Labs
> 
> --
> 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>

-- 
Kind regards,
Minchan Kim

  reply	other threads:[~2012-09-06  5:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-05  8:11 [PATCH 1/2] mm: change enum migrate_mode with bitwise type Minchan Kim
2012-09-05  8:11 ` Minchan Kim
2012-09-05  8:11 ` [PATCH 2/2] mm: support MIGRATE_DISCARD Minchan Kim
2012-09-05  8:11   ` Minchan Kim
2012-09-05 10:56   ` Mel Gorman
2012-09-05 10:56     ` Mel Gorman
2012-09-06  5:31     ` Minchan Kim [this message]
2012-09-06  5:31       ` Minchan Kim
2012-09-06  8:29       ` Mel Gorman
2012-09-06  8:29         ` Mel Gorman
2012-09-06  9:03         ` Mel Gorman
2012-09-06  9:03           ` Mel Gorman
2012-09-07  0:57           ` Kyungmin Park
2012-09-07  0:57             ` Kyungmin Park
2012-09-07  2:26             ` Minchan Kim
2012-09-07  2:26               ` Minchan Kim
2012-09-07  8:10               ` Mel Gorman
2012-09-07  8:10                 ` Mel Gorman
2012-09-07  2:24           ` Minchan Kim
2012-09-07  2:24             ` Minchan Kim
2012-09-07  5:57             ` Kyungmin Park
2012-09-07  5:57               ` Kyungmin Park
2012-09-07  7:31               ` Kyungmin Park
2012-09-07  7:31                 ` Kyungmin Park
2012-09-07  8:17                 ` Minchan Kim
2012-09-07  8:17                   ` Minchan Kim
2012-09-07  8:57                   ` Kyungmin Park
2012-09-07  8:57                     ` Kyungmin Park
2012-09-07  8:21             ` Mel Gorman
2012-09-07  8:21               ` Mel Gorman
2012-09-07  9:32               ` Mel Gorman
2012-09-07  9:32                 ` Mel Gorman
2012-09-08  0:16                 ` Minchan Kim
2012-09-08  0:16                   ` Minchan Kim
2012-09-05 12:43   ` Michal Nazarewicz
2012-09-05 12:43     ` Michal Nazarewicz
2012-12-21 13:04   ` lihanhui
2012-12-21 13:04     ` lihanhui
2012-09-05 12:41 ` [PATCH 1/2] mm: change enum migrate_mode with bitwise type Michal Nazarewicz
2012-09-05 12:41   ` Michal Nazarewicz

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=20120906053112.GA16231@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mgorman@suse.de \
    --cc=mina86@mina86.com \
    --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.