From: Andrew Morton <akpm@digeo.com>
To: frankeh@watson.ibm.com
Cc: Mark_H_Johnson@raytheon.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] recognize MAP_LOCKED in mmap() call
Date: Wed, 25 Sep 2002 09:35:40 -0700 [thread overview]
Message-ID: <3D91E5DC.665EB3AC@digeo.com> (raw)
In-Reply-To: 200209251142.29341.frankeh@watson.ibm.com
Hubertus Franke wrote:
>
> ...
> This is what the manpage says...
>
> mlockall disables paging for all pages mapped into the
> address space of the calling process. This includes the
> pages of the code, data and stack segment, as well as
> shared libraries, user space kernel data, shared memory
> and memory mapped files. All mapped pages are guaranteed
> to be resident in RAM when the mlockall system call
> returns successfully and they are guaranteed to stay in
> RAM until the pages are unlocked again by munlock or
> munlockall or until the process terminates or starts
> another program with exec. Child processes do not inherit
> page locks across a fork.
>
> Do you read that all pages must be faulted in apriori ?
For MCL_FUTURE.
> Or is it sufficient to to make sure non of the currently mapped
> pages are swapped out and future swapout is prohibited.
I'd say that we should try to make all the pages present. But
if it's a problem for (say) a hugepage implementation then it's
unlikely that the world would end if these things were still
demand paged in.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@digeo.com>
To: frankeh@watson.ibm.com
Cc: Mark_H_Johnson@raytheon.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] recognize MAP_LOCKED in mmap() call
Date: Wed, 25 Sep 2002 09:35:40 -0700 [thread overview]
Message-ID: <3D91E5DC.665EB3AC@digeo.com> (raw)
In-Reply-To: 200209251142.29341.frankeh@watson.ibm.com
Hubertus Franke wrote:
>
> ...
> This is what the manpage says...
>
> mlockall disables paging for all pages mapped into the
> address space of the calling process. This includes the
> pages of the code, data and stack segment, as well as
> shared libraries, user space kernel data, shared memory
> and memory mapped files. All mapped pages are guaranteed
> to be resident in RAM when the mlockall system call
> returns successfully and they are guaranteed to stay in
> RAM until the pages are unlocked again by munlock or
> munlockall or until the process terminates or starts
> another program with exec. Child processes do not inherit
> page locks across a fork.
>
> Do you read that all pages must be faulted in apriori ?
For MCL_FUTURE.
> Or is it sufficient to to make sure non of the currently mapped
> pages are swapped out and future swapout is prohibited.
I'd say that we should try to make all the pages present. But
if it's a problem for (say) a hugepage implementation then it's
unlikely that the world would end if these things were still
demand paged in.
--
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/
next prev parent reply other threads:[~2002-09-25 16:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-18 19:18 [PATCH] recognize MAP_LOCKED in mmap() call Mark_H_Johnson
2002-09-18 19:18 ` Mark_H_Johnson
2002-09-18 19:39 ` Rik van Riel
2002-09-18 19:39 ` Rik van Riel
2002-09-18 19:54 ` Andrew Morton
2002-09-18 19:54 ` Andrew Morton
2002-09-25 15:42 ` Hubertus Franke
2002-09-25 15:42 ` Hubertus Franke
2002-09-25 16:35 ` Andrew Morton [this message]
2002-09-25 16:35 ` Andrew Morton
2002-09-25 15:36 ` Hubertus Franke
2002-09-25 15:36 ` Hubertus Franke
-- strict thread matches above, loose matches on Subject: below --
2002-09-25 16:57 Mark_H_Johnson
2002-09-25 16:57 ` Mark_H_Johnson
2002-09-13 3:33 [PATCH] per-zone kswapd process Dave Hansen
2002-09-13 13:05 ` Alan Cox
2002-09-13 21:30 ` William Lee Irwin III
2002-09-18 16:07 ` [PATCH] recognize MAP_LOCKED in mmap() call Hubertus Franke
2002-09-18 16:29 ` Andrew Morton
2002-09-18 16:29 ` Andrew Morton
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=3D91E5DC.665EB3AC@digeo.com \
--to=akpm@digeo.com \
--cc=Mark_H_Johnson@raytheon.com \
--cc=frankeh@watson.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.