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

[Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

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