From: Mel Gorman <mgorman@suse.de>
To: Minchan Kim <minchan@kernel.org>
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 09:29:35 +0100 [thread overview]
Message-ID: <20120906082935.GN11266@suse.de> (raw)
In-Reply-To: <20120906053112.GA16231@bbox>
On Thu, Sep 06, 2012 at 02:31:12PM +0900, Minchan Kim wrote:
> 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?
Maintainability. There are reclaim functions and there are migration
functions. Your patch takes migrate_pages() and makes it partially a
reclaim function mixing up the responsibilities of migrate.c and vmscan.c.
> 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.
They could also have used the helper function from CMA that takes a list
of pages, reclaims some and migrates other.
> If you're not strong against with me, I would like to insist on my implementation.
>
I'm not very strongly against it but I'm also very unhappy.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Minchan Kim <minchan@kernel.org>
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 09:29:35 +0100 [thread overview]
Message-ID: <20120906082935.GN11266@suse.de> (raw)
In-Reply-To: <20120906053112.GA16231@bbox>
On Thu, Sep 06, 2012 at 02:31:12PM +0900, Minchan Kim wrote:
> 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?
Maintainability. There are reclaim functions and there are migration
functions. Your patch takes migrate_pages() and makes it partially a
reclaim function mixing up the responsibilities of migrate.c and vmscan.c.
> 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.
They could also have used the helper function from CMA that takes a list
of pages, reclaims some and migrates other.
> If you're not strong against with me, I would like to insist on my implementation.
>
I'm not very strongly against it but I'm also very unhappy.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2012-09-06 8: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
2012-09-06 5:31 ` Minchan Kim
2012-09-06 8:29 ` Mel Gorman [this message]
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=20120906082935.GN11266@suse.de \
--to=mgorman@suse.de \
--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=mina86@mina86.com \
--cc=minchan@kernel.org \
--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.