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-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
