[PATCH] remap_file_pages.2: Not actually useful on real files.

[PATCH] remap_file_pages.2: Not actually useful on real files.

[Andy Lutomirski]

Linux commit 3ee6dafc677a68e461a7ddafc94a580ebab80735 caused
remap_file_pages to be emulated when used on real file.

Signed-off-by: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
---
 man2/remap_file_pages.2 | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/man2/remap_file_pages.2 b/man2/remap_file_pages.2
index f96f594..f6dee99 100644
--- a/man2/remap_file_pages.2
+++ b/man2/remap_file_pages.2
@@ -148,6 +148,12 @@ The
 .BR remap_file_pages ()
 system call appeared in Linux 2.5.46;
 glibc support was added in version 2.3.3.
+
+.BR remap_file_pages ()
+has no performance advantage over
+.BR mmap (2)
+when used on real (as opposed to purely in-memory) files as of Linux 2.6.23:
+on real files it creates a separate vma for each range.
 .SH "CONFORMING TO"
 The
 .BR remap_file_pages ()
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Michael Kerrisk (man-pages)]

Andy,

It's long after the fact, but...

On 12/19/2012 11:12 PM, Andy Lutomirski wrote:
> Linux commit 3ee6dafc677a68e461a7ddafc94a580ebab80735 caused
> remap_file_pages to be emulated when used on real file.
> 
> Signed-off-by: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> ---
>  man2/remap_file_pages.2 | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/man2/remap_file_pages.2 b/man2/remap_file_pages.2
> index f96f594..f6dee99 100644
> --- a/man2/remap_file_pages.2
> +++ b/man2/remap_file_pages.2
> @@ -148,6 +148,12 @@ The
>  .BR remap_file_pages ()
>  system call appeared in Linux 2.5.46;
>  glibc support was added in version 2.3.3.
> +
> +.BR remap_file_pages ()
> +has no performance advantage over
> +.BR mmap (2)
> +when used on real (as opposed to purely in-memory) files as of Linux 2.6.23:
> +on real files it creates a separate vma for each range.
>  .SH "CONFORMING TO"
>  The
>  .BR remap_file_pages ()


I've applied the above. I then tweaked it a little. Is the following
okay:

[[
Since Linux 2.6.23,
.\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
.BR remap_file_pages ()
has no performance advantage over
.BR mmap (2)
when used on real files:
on real files it creates a separate VMA for each range.
It does, however, continue to provide a performance advantage
for files on memory-based filesystems.
]]

?

Cheers,

Michael




-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Christoph Hellwig]

On Thu, May 08, 2014 at 11:45:05AM +0200, Michael Kerrisk (man-pages) wrote:
> I've applied the above. I then tweaked it a little. Is the following
> okay:
> 
> [[
> Since Linux 2.6.23,
> .\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
> .BR remap_file_pages ()
> has no performance advantage over
> .BR mmap (2)
> when used on real files:
> on real files it creates a separate VMA for each range.
> It does, however, continue to provide a performance advantage
> for files on memory-based filesystems.
> ]]

I think "real file" is a very bad term.  What is more real about one
file vs another?  Is NFS less real than XFS, is tmpfs more real than
ramfs?

I'd reword this more like this:

Since Linux 2.6.23, remap_file_pages only creates non-linear mappings
on in-memory file systems like tmpfs, hugetlbfs or ramfs.  File systems
with a backing store provide a less efficient emulation.


I think the whole man page for remap_file_pages is a litt confusing I
have to say, the concept of a VMA is purely kernel internal and doesn't
really have a meaning for applications and thus shouldn't appear in a
man page.


While we're at it:  It seems like we should get rid of the remap_pages
vma operation - it's set by lots of filesystems that can never have
it invoked, and always is set to generic_file_remap_pages anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Michael Kerrisk (man-pages)]

Hi Christoph,

On Thu, May 8, 2014 at 2:50 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> On Thu, May 08, 2014 at 11:45:05AM +0200, Michael Kerrisk (man-pages) wrote:
>> I've applied the above. I then tweaked it a little. Is the following
>> okay:
>>
>> [[
>> Since Linux 2.6.23,
>> .\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
>> .BR remap_file_pages ()
>> has no performance advantage over
>> .BR mmap (2)
>> when used on real files:
>> on real files it creates a separate VMA for each range.
>> It does, however, continue to provide a performance advantage
>> for files on memory-based filesystems.
>> ]]
>
> I think "real file" is a very bad term.  What is more real about one
> file vs another?  Is NFS less real than XFS, is tmpfs more real than
> ramfs?
>
> I'd reword this more like this:
>
> Since Linux 2.6.23, remap_file_pages only creates non-linear mappings
> on in-memory file systems like tmpfs, hugetlbfs or ramfs.  File systems
> with a backing store provide a less efficient emulation.

Yes, sounds better to me. Any tweaks you want to add to that, Andy?

> I think the whole man page for remap_file_pages is a litt confusing I
> have to say, the concept of a VMA is purely kernel internal and doesn't
> really have a meaning for applications and thus shouldn't appear in a
> man page.

I agree it could be better. Do you have a suggested text?

> While we're at it:  It seems like we should get rid of the remap_pages
> vma operation - it's set by lots of filesystems that can never have
> it invoked, and always is set to generic_file_remap_pages anyway.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Andy Lutomirski]

On Thu, May 8, 2014 at 6:29 AM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Christoph,
>
> On Thu, May 8, 2014 at 2:50 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>> On Thu, May 08, 2014 at 11:45:05AM +0200, Michael Kerrisk (man-pages) wrote:
>>> I've applied the above. I then tweaked it a little. Is the following
>>> okay:
>>>
>>> [[
>>> Since Linux 2.6.23,
>>> .\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
>>> .BR remap_file_pages ()
>>> has no performance advantage over
>>> .BR mmap (2)
>>> when used on real files:
>>> on real files it creates a separate VMA for each range.
>>> It does, however, continue to provide a performance advantage
>>> for files on memory-based filesystems.
>>> ]]
>>
>> I think "real file" is a very bad term.  What is more real about one
>> file vs another?  Is NFS less real than XFS, is tmpfs more real than
>> ramfs?
>>
>> I'd reword this more like this:
>>
>> Since Linux 2.6.23, remap_file_pages only creates non-linear mappings
>> on in-memory file systems like tmpfs, hugetlbfs or ramfs.  File systems
>> with a backing store provide a less efficient emulation.
>
> Yes, sounds better to me. Any tweaks you want to add to that, Andy?
>
>> I think the whole man page for remap_file_pages is a litt confusing I
>> have to say, the concept of a VMA is purely kernel internal and doesn't
>> really have a meaning for applications and thus shouldn't appear in a
>> man page.
>
> I agree it could be better. Do you have a suggested text?
>
>> While we're at it:  It seems like we should get rid of the remap_pages
>> vma operation - it's set by lots of filesystems that can never have
>> it invoked, and always is set to generic_file_remap_pages anyway.

Something along the lines of "on filesystems with a backing store,
remap_file_pages is not much more efficient than using mmap(2) to
adjust which parts of the file are mapped to which addresses" might
get the idea across.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Michael Kerrisk (man-pages)]

On 05/08/2014 10:38 PM, Andy Lutomirski wrote:
> On Thu, May 8, 2014 at 6:29 AM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Christoph,
>>
>> On Thu, May 8, 2014 at 2:50 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>>> On Thu, May 08, 2014 at 11:45:05AM +0200, Michael Kerrisk (man-pages) wrote:
>>>> I've applied the above. I then tweaked it a little. Is the following
>>>> okay:
>>>>
>>>> [[
>>>> Since Linux 2.6.23,
>>>> .\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
>>>> .BR remap_file_pages ()
>>>> has no performance advantage over
>>>> .BR mmap (2)
>>>> when used on real files:
>>>> on real files it creates a separate VMA for each range.
>>>> It does, however, continue to provide a performance advantage
>>>> for files on memory-based filesystems.
>>>> ]]
>>>
>>> I think "real file" is a very bad term.  What is more real about one
>>> file vs another?  Is NFS less real than XFS, is tmpfs more real than
>>> ramfs?
>>>
>>> I'd reword this more like this:
>>>
>>> Since Linux 2.6.23, remap_file_pages only creates non-linear mappings
>>> on in-memory file systems like tmpfs, hugetlbfs or ramfs.  File systems
>>> with a backing store provide a less efficient emulation.
>>
>> Yes, sounds better to me. Any tweaks you want to add to that, Andy?
>>
>>> I think the whole man page for remap_file_pages is a litt confusing I
>>> have to say, the concept of a VMA is purely kernel internal and doesn't
>>> really have a meaning for applications and thus shouldn't appear in a
>>> man page.
>>
>> I agree it could be better. Do you have a suggested text?
>>
>>> While we're at it:  It seems like we should get rid of the remap_pages
>>> vma operation - it's set by lots of filesystems that can never have
>>> it invoked, and always is set to generic_file_remap_pages anyway.
> 
> Something along the lines of "on filesystems with a backing store,
> remap_file_pages is not much more efficient than using mmap(2) to
> adjust which parts of the file are mapped to which addresses" might
> get the idea across.

So, now I have:

[[
Since Linux 2.6.23,
.\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
.BR remap_file_pages ()
creates non-linear mappings only on
on in-memory file systems such as tmpfs, hugetlbfs or ramfs.
On filesystems with a backing store,
.BR remap_file_pages ()
is not much more efficient than using
.BR mmap (2)
to adjust which parts of the file are mapped to which addresses.
]]

Okay?

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Andy Lutomirski]

On Thu, May 8, 2014 at 10:31 PM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 05/08/2014 10:38 PM, Andy Lutomirski wrote:
>> On Thu, May 8, 2014 at 6:29 AM, Michael Kerrisk (man-pages)
>> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Hi Christoph,
>>>
>>> On Thu, May 8, 2014 at 2:50 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>>>> On Thu, May 08, 2014 at 11:45:05AM +0200, Michael Kerrisk (man-pages) wrote:
>>>>> I've applied the above. I then tweaked it a little. Is the following
>>>>> okay:
>>>>>
>>>>> [[
>>>>> Since Linux 2.6.23,
>>>>> .\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
>>>>> .BR remap_file_pages ()
>>>>> has no performance advantage over
>>>>> .BR mmap (2)
>>>>> when used on real files:
>>>>> on real files it creates a separate VMA for each range.
>>>>> It does, however, continue to provide a performance advantage
>>>>> for files on memory-based filesystems.
>>>>> ]]
>>>>
>>>> I think "real file" is a very bad term.  What is more real about one
>>>> file vs another?  Is NFS less real than XFS, is tmpfs more real than
>>>> ramfs?
>>>>
>>>> I'd reword this more like this:
>>>>
>>>> Since Linux 2.6.23, remap_file_pages only creates non-linear mappings
>>>> on in-memory file systems like tmpfs, hugetlbfs or ramfs.  File systems
>>>> with a backing store provide a less efficient emulation.
>>>
>>> Yes, sounds better to me. Any tweaks you want to add to that, Andy?
>>>
>>>> I think the whole man page for remap_file_pages is a litt confusing I
>>>> have to say, the concept of a VMA is purely kernel internal and doesn't
>>>> really have a meaning for applications and thus shouldn't appear in a
>>>> man page.
>>>
>>> I agree it could be better. Do you have a suggested text?
>>>
>>>> While we're at it:  It seems like we should get rid of the remap_pages
>>>> vma operation - it's set by lots of filesystems that can never have
>>>> it invoked, and always is set to generic_file_remap_pages anyway.
>>
>> Something along the lines of "on filesystems with a backing store,
>> remap_file_pages is not much more efficient than using mmap(2) to
>> adjust which parts of the file are mapped to which addresses" might
>> get the idea across.
>
> So, now I have:
>
> [[
> Since Linux 2.6.23,
> .\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
> .BR remap_file_pages ()
> creates non-linear mappings only on
> on in-memory file systems such as tmpfs, hugetlbfs or ramfs.
> On filesystems with a backing store,
> .BR remap_file_pages ()
> is not much more efficient than using
> .BR mmap (2)
> to adjust which parts of the file are mapped to which addresses.
> ]]
>
> Okay?

I think so, except for the "on on".

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Michael Kerrisk (man-pages)]

On Sat, May 10, 2014 at 2:57 AM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> On Thu, May 8, 2014 at 10:31 PM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 05/08/2014 10:38 PM, Andy Lutomirski wrote:
>>> On Thu, May 8, 2014 at 6:29 AM, Michael Kerrisk (man-pages)
>>> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> Hi Christoph,
>>>>
>>>> On Thu, May 8, 2014 at 2:50 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>>>>> On Thu, May 08, 2014 at 11:45:05AM +0200, Michael Kerrisk (man-pages) wrote:
>>>>>> I've applied the above. I then tweaked it a little. Is the following
>>>>>> okay:
>>>>>>
>>>>>> [[
>>>>>> Since Linux 2.6.23,
>>>>>> .\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
>>>>>> .BR remap_file_pages ()
>>>>>> has no performance advantage over
>>>>>> .BR mmap (2)
>>>>>> when used on real files:
>>>>>> on real files it creates a separate VMA for each range.
>>>>>> It does, however, continue to provide a performance advantage
>>>>>> for files on memory-based filesystems.
>>>>>> ]]
>>>>>
>>>>> I think "real file" is a very bad term.  What is more real about one
>>>>> file vs another?  Is NFS less real than XFS, is tmpfs more real than
>>>>> ramfs?
>>>>>
>>>>> I'd reword this more like this:
>>>>>
>>>>> Since Linux 2.6.23, remap_file_pages only creates non-linear mappings
>>>>> on in-memory file systems like tmpfs, hugetlbfs or ramfs.  File systems
>>>>> with a backing store provide a less efficient emulation.
>>>>
>>>> Yes, sounds better to me. Any tweaks you want to add to that, Andy?
>>>>
>>>>> I think the whole man page for remap_file_pages is a litt confusing I
>>>>> have to say, the concept of a VMA is purely kernel internal and doesn't
>>>>> really have a meaning for applications and thus shouldn't appear in a
>>>>> man page.
>>>>
>>>> I agree it could be better. Do you have a suggested text?
>>>>
>>>>> While we're at it:  It seems like we should get rid of the remap_pages
>>>>> vma operation - it's set by lots of filesystems that can never have
>>>>> it invoked, and always is set to generic_file_remap_pages anyway.
>>>
>>> Something along the lines of "on filesystems with a backing store,
>>> remap_file_pages is not much more efficient than using mmap(2) to
>>> adjust which parts of the file are mapped to which addresses" might
>>> get the idea across.
>>
>> So, now I have:
>>
>> [[
>> Since Linux 2.6.23,
>> .\" commit 3ee6dafc677a68e461a7ddafc94a580ebab80735
>> .BR remap_file_pages ()
>> creates non-linear mappings only on
>> on in-memory file systems such as tmpfs, hugetlbfs or ramfs.
>> On filesystems with a backing store,
>> .BR remap_file_pages ()
>> is not much more efficient than using
>> .BR mmap (2)
>> to adjust which parts of the file are mapped to which addresses.
>> ]]
>>
>> Okay?
>
> I think so, except for the "on on".

Thanks, Andy. Fixed.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Christoph Hellwig]

On Thu, May 08, 2014 at 03:29:32PM +0200, Michael Kerrisk (man-pages) wrote:
> > I think the whole man page for remap_file_pages is a litt confusing I
> > have to say, the concept of a VMA is purely kernel internal and doesn't
> > really have a meaning for applications and thus shouldn't appear in a
> > man page.
> 
> I agree it could be better. Do you have a suggested text?

Does the patch below look good?  I tries to explain it in user visible
behavior:


diff --git a/man2/remap_file_pages.2 b/man2/remap_file_pages.2
index 67251e3..716b911 100644
--- a/man2/remap_file_pages.2
+++ b/man2/remap_file_pages.2
@@ -46,8 +46,7 @@ The advantage of using
 .BR remap_file_pages ()
 over using repeated calls to
 .BR mmap (2)
-is that the former approach does not require the kernel to create
-additional VMA (Virtual Memory Area) data structures.
+is that the kernel can implement it more efficiently.
 
 To create a nonlinear mapping we perform the following steps:
 .TP 3
@@ -160,11 +159,18 @@ Since Linux 2.6.23,
 .BR remap_file_pages ()
 creates non-linear mappings only
 on in-memory file systems such as tmpfs, hugetlbfs or ramfs.
+
 On filesystems with a backing store,
 .BR remap_file_pages ()
 is not much more efficient than using
 .BR mmap (2)
 to adjust which parts of the file are mapped to which addresses.
+
+Non-linear mappings created by
+.BR remap_file_pages ()
+do not count against the limit of memory mappings set in
+.I /proc/sys/vm/max_map_count
+unless the above mentioned emulation is used.
 .SH SEE ALSO
 .BR getpagesize (2),
 .BR mmap (2),
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remap_file_pages.2: Not actually useful on real files.

[Andy Lutomirski]

On Mon, May 19, 2014 at 7:48 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> On Thu, May 08, 2014 at 03:29:32PM +0200, Michael Kerrisk (man-pages) wrote:
>> > I think the whole man page for remap_file_pages is a litt confusing I
>> > have to say, the concept of a VMA is purely kernel internal and doesn't
>> > really have a meaning for applications and thus shouldn't appear in a
>> > man page.
>>
>> I agree it could be better. Do you have a suggested text?
>
> Does the patch below look good?  I tries to explain it in user visible
> behavior:
>
>
> diff --git a/man2/remap_file_pages.2 b/man2/remap_file_pages.2
> index 67251e3..716b911 100644
> --- a/man2/remap_file_pages.2
> +++ b/man2/remap_file_pages.2
> @@ -46,8 +46,7 @@ The advantage of using
>  .BR remap_file_pages ()
>  over using repeated calls to
>  .BR mmap (2)
> -is that the former approach does not require the kernel to create
> -additional VMA (Virtual Memory Area) data structures.
> +is that the kernel can implement it more efficiently.
>
>  To create a nonlinear mapping we perform the following steps:
>  .TP 3
> @@ -160,11 +159,18 @@ Since Linux 2.6.23,
>  .BR remap_file_pages ()
>  creates non-linear mappings only
>  on in-memory file systems such as tmpfs, hugetlbfs or ramfs.
> +
>  On filesystems with a backing store,
>  .BR remap_file_pages ()
>  is not much more efficient than using
>  .BR mmap (2)
>  to adjust which parts of the file are mapped to which addresses.
> +
> +Non-linear mappings created by
> +.BR remap_file_pages ()
> +do not count against the limit of memory mappings set in
> +.I /proc/sys/vm/max_map_count
> +unless the above mentioned emulation is used.
>  .SH SEE ALSO
>  .BR getpagesize (2),
>  .BR mmap (2),

This could be misread as saying that, on real filesystems,
remap_file_pages isn't more efficient but still avoids max_map_count.
I think that this is not the case.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html