Armin Rigo wrote: > Hi everybody, > > Here is a note from the PyPy project (mentioned earlier in this > thread, and at https://lwn.net/Articles/587923/ ). > > Yes, we use remap_file_pages() heavily on the x86-64 architecture. > However, the individual calls to remap_file_pages() are not > performance-critical, so it is easy to switch to using multiple > mmap()s. We need to perform more measurements to know exactly what > the overhead would be, in terms notably of kernel memory. > > However, an issue with that approach is the upper bound on the number > of VMAs. By default, it is not large enough. Right now, it is > possible to remap say 10% of the individual pages from an anonymous > mmap of multiple GBs in size; but doing so with individual calls to > mmap hits this arbitrary limit. The limit is not totaly random. We use ELF format for coredumps and ELF has limitation (16-bit field) on number of sections it can store. With ELF extended numbering we can bypass 16-bit limit, but some userspace can be surprised by that. > I have no particular weight to give > for or against keeping remap_file_pages() in the kernel, but if it is > removed or emulated, it would be a plus if the programs would run on a > machine with the default configuration --- i.e. if you remove or > emulate remap_file_pages(), please increase the default limit as well. It's fine to me. Andrew? -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>