All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Minchan Kim <minchan@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Rik van Riel <riel@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	tglx@linutronix.de, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Theodore Ts'o <tytso@mit.edu>
Subject: Re: Allow migration of mlocked page?
Date: Mon, 14 May 2012 14:39:45 +0100	[thread overview]
Message-ID: <20120514133944.GF29102@suse.de> (raw)
In-Reply-To: <4FB08920.4010001@kernel.org>

On Mon, May 14, 2012 at 01:25:04PM +0900, Minchan Kim wrote:
> > <SNIP>
> >
> > If CMA decide they want to alter mlocked pages in this way, it's sortof
> > ok. While CMA is being used, there are no expectations on the RT
> > behaviour of the system - stalls are expected. In their use cases, CMA
> > failing is far worse than access latency to an mlocked page being
> > variable while CMA is running.
> > 
> > Compaction on the other hand is during the normal operation of the
> > machine. There are applications that assume that if anonymous memory
> > is mlocked() then access to it is close to zero latency. They are
> > not RT-critical processes (or they would disable THP) but depend on
> > this. Allowing compaction to migrate mlocked() pages will result in bugs
> > being reported by these people.
> > 
> > I've received one bug this year about access latency to mlocked() regions but
> > it turned out to be a file-backed region and related to when the write-fault
> > is incurred. The ultimate fix was in the application but we'll get new bug
> > reports if anonymous mlocked pages do not preserve the current guarantees
> > on access latency.
> > 
> 
> If so, what do you think about migration of mlocked pages by migrate_pages, cpuset_migrate_mm and memcg?

migrate_pages() is a core function used by a variety of different callers. It
*optionally* could move mlocked pages and it would be up to the caller to
specify if that was allowed.

cpuset_migrate_mm() should be allowed to move mlocked() pages because it's
called in a path where the pages are on a node that should not longer be
accessible to the processes. In this case, the latency hit is unavoidable
and a bug reporter that says "there is an unexpected latency accessing memory
while a process moves memory to another node" will be told to get a clue.

Where does memcg call migrate_pages()?

> I think they all is done by under user's control while compaction happens regardless of user.
> So do you think that's why compaction shouldn't migrate mlocked page?
> 

Yes. If the user takes an explicit action that causes latencies when
accessing an mlocked anonymous region while the pages are migrated, that's
fine. I still do not think that THP and khugepaged should cause unexpected
latencies accessing mlocked anonymous regions because it is beyond the
control of the application.

-- 
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/ .
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:[~2012-05-14 13:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-11  4:37 Allow migration of mlocked page? Minchan Kim
2012-05-11  9:20 ` Peter Zijlstra
2012-05-11 16:20   ` Christoph Lameter
2012-05-11 23:24     ` KOSAKI Motohiro
2012-05-14 13:45       ` Christoph Lameter
2012-05-14  4:13   ` Minchan Kim
2012-05-14  6:56     ` Peter Zijlstra
2012-05-14  7:37       ` Minchan Kim
2012-05-14  7:45         ` Peter Zijlstra
2012-05-14  7:49           ` Peter Zijlstra
2012-05-14  7:54             ` Minchan Kim
2012-05-14 13:47         ` Christoph Lameter
2012-05-15  1:23           ` Minchan Kim
2012-05-15 11:07             ` Peter Zijlstra
2012-05-11 13:14 ` Mel Gorman
2012-05-11 23:25   ` KOSAKI Motohiro
2012-05-14 13:32     ` Mel Gorman
2012-05-14 13:51       ` Peter Zijlstra
2012-05-14 14:01         ` Christoph Lameter
2012-05-14 14:14           ` Peter Zijlstra
2012-05-14 14:43             ` Christoph Lameter
2012-05-14 22:52               ` KOSAKI Motohiro
2012-05-14 23:04             ` Roland Dreier
2012-05-15 14:27               ` Christoph Lameter
2012-05-15  1:38           ` Minchan Kim
2012-05-14 14:08         ` Peter Zijlstra
2012-05-14 23:06       ` KOSAKI Motohiro
2012-05-15  1:35       ` Minchan Kim
2012-05-14  4:25   ` Minchan Kim
2012-05-14 13:39     ` Mel Gorman [this message]
2012-05-15  2:15       ` Minchan Kim
2012-05-15  4:33         ` KOSAKI Motohiro
2012-05-15 11:06           ` Peter Zijlstra
2012-05-15 14:12             ` Christoph Lameter
2012-05-15 14:45               ` Peter Zijlstra
2012-05-15 15:11                 ` Christoph Lameter
2012-05-15 14:10           ` Christoph Lameter
2012-05-15 14:09         ` 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=20120514133944.GF29102@suse.de \
    --to=mgorman@suse.de \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    /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.