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