[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150428161001.e854fb3eaf82f738865130af@linux-foundation.org>
Date: Tue, 28 Apr 2015 16:10:01 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Michal Hocko <mhocko@...e.cz>
Cc: linux-mm@...ck.org, Cyril Hrubis <chrubis@...e.cz>,
Hugh Dickins <hughd@...gle.com>,
Michel Lespinasse <walken@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Michael Kerrisk <mtk.manpages@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [RFC 1/3] mm: mmap make MAP_LOCKED really mlock semantic
On Tue, 28 Apr 2015 14:11:49 +0200 Michal Hocko <mhocko@...e.cz> wrote:
> The man page however says
> "
> MAP_LOCKED (since Linux 2.5.37)
> Lock the pages of the mapped region into memory in the manner of
> mlock(2). This flag is ignored in older kernels.
> "
I'm trying to remember why we implemented MAP_LOCKED in the first
place. Was it better than mmap+mlock in some fashion?
afaict we had a #define MAP_LOCKED in the header file but it wasn't
implemented, so we went and wired it up. 13 years ago:
https://lkml.org/lkml/2002/9/18/108
Anyway... the third way of doing this is to use plain old mmap() while
mlockall(MCL_FUTURE) is in force. Has anyone looked at that, checked
that the behaviour is sane and compared it with the mmap+mlock
behaviour, the MAP_LOCKED behaviour and the manpages?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists