From: Gleb Natapov <gleb@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
linux-mm@kvack.org, kosaki.motohiro@jp.fujitsu.com,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
akpm@linux-foundation.org, andrew.c.morrow@gmail.com,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH v6] add MAP_UNLOCKED mmap flag
Date: Tue, 19 Jan 2010 09:17:34 +0200 [thread overview]
Message-ID: <20100119071734.GG14345@redhat.com> (raw)
In-Reply-To: <20100118191031.0088f49a@lxorguk.ukuu.org.uk>
On Mon, Jan 18, 2010 at 07:10:31PM +0000, Alan Cox wrote:
> > I can't realistically chase every address space mapping changes and mlock
> > new areas. The only way other then mlockall() is to use custom memory
> > allocator that allocates mlocked memory.
>
> Which keeps all the special cases in your app rather than in every single
> users kernel. That seems to be the right way up, especially as you can
> make a library of it !
>
Are you advocating rewriting mlockall() in userspace? It may be possible,
but will require rewriting half of libc. Everything that changes process
address space should support mlocking (memory allocation functions, dynamic
loading, strdup). Allocations can be done only with mmap() since brk()
can allocate mlocked memory atomically. And of course if third party library
uses mmap syscall directly instead of using libc one you are SOL. Been
there already, worked on project that replaced libc memory allocations functions
because it had to track when memory is returned to OS, not just internal
libc pool (MPI). This is pain in the arse and on top of that it doesn't work
reliably. Some things are better be done on OS level.
The thread took a direction of bashing mlockall(). This is especially
strange since proposed patch actually makes mlockall() more fine
grained and thus more useful.
--
Gleb.
--
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>
next prev parent reply other threads:[~2010-01-19 7:17 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-18 13:37 [PATCH v6] add MAP_UNLOCKED mmap flag Gleb Natapov
[not found] ` <20100118133755.GG30698-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-18 14:09 ` Pekka Enberg
2010-01-18 14:19 ` Gleb Natapov
2010-01-18 14:32 ` Alan Cox
2010-01-18 14:35 ` Gleb Natapov
2010-01-18 14:49 ` Peter Zijlstra
2010-01-18 15:01 ` Gleb Natapov
2010-01-18 15:06 ` Peter Zijlstra
2010-01-18 15:11 ` Avi Kivity
2010-01-18 15:14 ` Peter Zijlstra
2010-01-18 15:19 ` Avi Kivity
[not found] ` <4B547C09.8010906-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-18 15:24 ` Peter Zijlstra
2010-01-18 15:41 ` Alan Cox
2010-01-18 15:44 ` Peter Zijlstra
2010-01-18 17:11 ` Gleb Natapov
2010-01-18 15:14 ` Gleb Natapov
2010-01-19 0:12 ` KOSAKI Motohiro
2010-01-18 16:05 ` Pekka Enberg
2010-01-18 17:08 ` Gleb Natapov
2010-01-18 18:09 ` Pekka Enberg
2010-01-18 18:19 ` Gleb Natapov
2010-01-18 19:10 ` Alan Cox
2010-01-19 7:17 ` Gleb Natapov [this message]
2010-01-19 7:37 ` Pekka Enberg
2010-01-19 7:52 ` Gleb Natapov
[not found] ` <20100119075205.GI14345-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-19 8:07 ` Pekka Enberg
2010-01-19 8:26 ` Gleb Natapov
[not found] ` <20100119082638.GK14345-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-19 8:44 ` Pekka Enberg
2010-01-19 10:40 ` Gleb Natapov
[not found] ` <84144f021001190044s397c6665qb00af48235d2d818-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-19 12:48 ` Minchan Kim
2010-01-19 13:18 ` Pekka Enberg
2010-01-19 13:26 ` Gleb Natapov
2010-01-20 0:24 ` KOSAKI Motohiro
2010-01-19 11:54 ` Alan Cox
2010-01-19 12:07 ` Gleb Natapov
2010-01-19 13:21 ` Alan Cox
2010-01-19 14:07 ` Minchan Kim
2010-01-19 14:14 ` Gleb Natapov
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=20100119071734.GG14345@redhat.com \
--to=gleb@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrew.c.morrow@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=penberg@cs.helsinki.fi \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).