On Sat, May 10, 2014 at 2:57 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Thu, May 8, 2014 at 10:31 PM, Michael Kerrisk (man-pages) > <mtk.manpages@xxxxxxxxx> 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@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. >> >> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
