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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 8, 2014 at 6:29 AM, Michael Kerrisk (man-pages)
<mtk.manpages@xxxxxxxxx> wrote:
> Hi Christoph,
>
> On Thu, May 8, 2014 at 2:50 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> 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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux