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. 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. 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. -- 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
