All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Mel Gorman <mgorman@suse.de>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Minchan Kim <minchan@kernel.org>,
	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>,
	Theodore Ts'o <tytso@mit.edu>
Subject: Re: Allow migration of mlocked page?
Date: Mon, 14 May 2012 15:51:55 +0200	[thread overview]
Message-ID: <1337003515.2443.35.camel@twins> (raw)
In-Reply-To: <20120514133210.GE29102@suse.de>

On Mon, 2012-05-14 at 14:32 +0100, Mel Gorman wrote:

> Embedded does not imply realtime constraints.
> 
> > So, I don't think
> > CMA and compaction are significantly different.
> > 
> 
> CMA is used in cases such as a mobile phone needing to allocate a large
> contiguous range of memory for video decoding. Compaction is used by
> features such as THP with khugepaged potentially using it frequently on
> x86-64 machines. The use cases are different and compaction is used by
> THP a lot more than CMA is used by anything.
> 
> If compaction can move mlocked pages then khugepaged can introduce unexpected
> latencies on mlocked anonymous regions of memory.

I'd like to see CMA used for memcg and things as well, where we only
allocate the shadow page frames on-demand.

This moves CMA out of the crappy hardware-only section and should result
in pretty much everybody using it (except me, since I have cgroup=n).

Anyway, THP isn't an issue for -rt, its impossible to select when you
have PREEMPT_RT.

> > >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.
> > 
> > Can you please tell us your opinion about autonuma?
> 
> I think it will have the same problem as THP using compaction. If
> mlocked pages can move then there may be unexpected latencies accessing
> mlocked anonymous regions.

numa and rt don't mix anyway.. don't worry about that.

> > I doubt we can keep such
> > mlock guarantee. I think we need to suggest application fix. maybe to introduce
> > MADV_UNMOVABLE is good start. it seems to solve autonuma issue too.
> > 
> 
> That'll regress existing applications. It would be preferable to me that
> it be the other way around to not move mlocked pages unless the user says
> it's allowed.

I'd say go for it, I've been telling everybody who would listen that
mlock() only means no major faults for a very long time now.



--
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:52 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 [this message]
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
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=1337003515.2443.35.camel@twins \
    --to=peterz@infradead.org \
    --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=kosaki.motohiro@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=mingo@redhat.com \
    --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.