The possible demise of remap_file_pages()

Posted May 8, 2014 7:48 UTC (Thu) by kiryl (subscriber, #41516)
Parent article: The possible demise of remap_file_pages()

> But that removal will go nowhere if it constitutes an ABI break.

It doesn't break ABI. remap_file_pages() backed by nonlinear mappings is replaced by the patchset with an emulation which creates multiple VMAs. It's slower but not an ABI break.

The possible demise of remap_file_pages()

Posted May 9, 2014 13:52 UTC (Fri) by chrish (guest, #351) [Link] (1 responses)

PyPY's software transactional memory branch is a heavy user of remap_file_pages(). Not sure if this approach would still be practical with that slowdown...

The possible demise of remap_file_pages()

Posted May 9, 2014 14:30 UTC (Fri) by chrish (guest, #351) [Link]

Apparently, it would be good enough for PyPy. From Armin, on the PyPy-dev mailing list: "I've explained the PyPy situation, and it looks now like they're going to replace remap_file_pages() with an emulation based on mmap() and, I hope, take care of the issue that the mmap() solution is limited to 65536 by default (i.e., increase the default limit). This would be good enough for PyPy, where the calls to remap_file_pages() are themselves not highly performance-critical."

(https://mail.python.org/pipermail/pypy-dev/2014-May/01247...)