lkml.org 
[lkml]   [2002]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] recognize MAP_LOCKED in mmap() call
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.272 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site