On Thu, May 08, 2014 at 03:29:32PM +0200, Michael Kerrisk (man-pages) wrote: > > 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? Does the patch below look good? I tries to explain it in user visible behavior: diff --git a/man2/remap_file_pages.2 b/man2/remap_file_pages.2 index 67251e3..716b911 100644 --- a/man2/remap_file_pages.2 +++ b/man2/remap_file_pages.2 @@ -46,8 +46,7 @@ The advantage of using .BR remap_file_pages () over using repeated calls to .BR mmap (2) -is that the former approach does not require the kernel to create -additional VMA (Virtual Memory Area) data structures. +is that the kernel can implement it more efficiently. To create a nonlinear mapping we perform the following steps: .TP 3 @@ -160,11 +159,18 @@ Since Linux 2.6.23, .BR remap_file_pages () creates non-linear mappings only 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. + +Non-linear mappings created by +.BR remap_file_pages () +do not count against the limit of memory mappings set in +.I /proc/sys/vm/max_map_count +unless the above mentioned emulation is used. .SH SEE ALSO .BR getpagesize (2), .BR mmap (2), -- 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
