Thread (1 message) 1 message, 1 author, 2014-05-10

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

From: Michael Kerrisk (man-pages) <hidden>
Date: 2014-05-10 17:44:52
Also in: linux-fsdevel

On Sat, May 10, 2014 at 2:57 AM, Andy Lutomirski [off-list ref] wrote:
On Thu, May 8, 2014 at 10:31 PM, Michael Kerrisk (man-pages)
[off-list ref] wrote:
quoted
On 05/08/2014 10:38 PM, Andy Lutomirski wrote:
quoted
On Thu, May 8, 2014 at 6:29 AM, Michael Kerrisk (man-pages)
[off-list ref] wrote:
quoted
Hi Christoph,

On Thu, May 8, 2014 at 2:50 PM, Christoph Hellwig [off-list ref] wrote:
quoted
On Thu, May 08, 2014 at 11:45:05AM +0200, Michael Kerrisk (man-pages) wrote:
quoted
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?
quoted
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?
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help