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". --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
