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

[Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>]

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