All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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.