On Mon, May 19, 2014 at 7:48 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > 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), This could be misread as saying that, on real filesystems, remap_file_pages isn't more efficient but still avoids max_map_count. I think that this is not the case. -- 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
