This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ztane
Recipients StyXman, bar.harel, dw, jtaylor, neologix, pitrou, vstinner, ztane
Date 2016-04-22.11:35:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1461324910.26.0.673523767.issue26601@psf.upfronthosting.co.za>
In-reply-to
Content
mmap is not the problem, the eagerness of munmap is a source of possible problem. 

The munmap eagerness does not show problems in all programs because the arena allocation heuristics do not work as intended. A proper solution in Linux and other operating systems where it is supported, is to put the freed arenas in a list, then mark freed with MADV_FREE. Now if the memory pressure grows, only *then* will the OS reclaim these. At any time the application can start reusing these arenas/pages; if they're not reclaimed, the old contents will be still present there; if operating system reclaimed them, they'd be remapped with zeroes.

Really the only downside of all this that I can foresee is that `ps/top/whatever` output would see Python using way more memory in its RSS/virt/whatever than it is actually using.
History
Date User Action Args
2016-04-22 11:35:10ztanesetrecipients: + ztane, pitrou, vstinner, StyXman, neologix, jtaylor, dw, bar.harel
2016-04-22 11:35:10ztanesetmessageid: <1461324910.26.0.673523767.issue26601@psf.upfronthosting.co.za>
2016-04-22 11:35:10ztanelinkissue26601 messages
2016-04-22 11:35:10ztanecreate