From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx113.postini.com [74.125.245.113]) by kanga.kvack.org (Postfix) with SMTP id A05D58D0001 for ; Fri, 11 May 2012 05:20:40 -0400 (EDT) Message-ID: <1336728026.1017.7.camel@twins> Subject: Re: Allow migration of mlocked page? From: Peter Zijlstra Date: Fri, 11 May 2012 11:20:26 +0200 In-Reply-To: <4FAC9786.9060200@kernel.org> References: <4FAC9786.9060200@kernel.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: Johannes Weiner , Mel Gorman , Rik van Riel , Andrew Morton , Andrea Arcangeli , KAMEZAWA Hiroyuki , Christoph Lameter , "linux-mm@kvack.org" , tglx@linutronix.de, Ingo Molnar , Theodore Ts'o On Fri, 2012-05-11 at 13:37 +0900, Minchan Kim wrote: > I hope hear opinion from rt guys, too. Its a problem yes, not sure your solution is any good though. As it stands mlock() simply doesn't guarantee no faults, all it does is guarantee no major faults. Are you saying compaction doesn't actually move mlocked pages? I'm somewhat surprised by that, I've always assumed it would. Its sad that mlock() doesn't take a flags argument, so I'd rather introduce a new madvise() flag for -rt, something like MADV_UNMOVABLE (or whatever) which will basically copy the pages to an un-movable page block and really pin the things. That way mlock() can stay what the spec says it is and guarantee residency. -- 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: email@kvack.org