[issue36139] release GIL on mmap dealloc

STINNER Victor added the comment: Yeah! Roundup is fixed, thanks Ezio! -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36139] release GIL on mmap dealloc

STINNER Victor added the comment: 4th attempt (sorry for the spam, it's just to check the Roundup fix!): https://github.com/python/cpython/pull/12073/files#r263026496 -- ___ Python tracker __

[issue36139] release GIL on mmap dealloc

Ezio Melotti added the comment: > Oh wow, that's really strange. I'm sure that I wrote "https://..."; URL but my > URL became "r263026496">https://..."; !? The links are now fixed (Roundup was getting confused by the rNN, since it looks like a SVN revision). -- nosy: +ezio.melot

[issue36139] release GIL on mmap dealloc

STINNER Victor added the comment: New changeset dc078947a5033a048d804e244e847b5844734439 by Victor Stinner (Davide Rizzo) in branch 'master': bpo-36139: Fix mmap_object_dealloc(): hold the GIL to call PyMem_Free() (GH-12199) https://github.com/python/cpython/commit/dc078947a5033a048d804e244e

[issue36139] release GIL on mmap dealloc

STINNER Victor added the comment: The second commit does fix the regression (I tested manually on Windows with Python compiled in debug mode). -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue36139] release GIL on mmap dealloc

Davide Rizzo added the comment: BTW should this be backported to 3.7? -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue36139] release GIL on mmap dealloc

Davide Rizzo added the comment: Thanks Victor. I think this fixes it https://github.com/python/cpython/pull/12199 -- ___ Python tracker ___ __

[issue36139] release GIL on mmap dealloc

Change by Davide Rizzo : -- pull_requests: +12194 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue36139] release GIL on mmap dealloc

STINNER Victor added the comment: """ r263026496">https://github.com/python/cpython/pull/12073/files#r263026496 """ Oh wow, that's really strange. I'm sure that I wrote "https://..."; URL but my URL became "r263026496">https://..."; !? 3rd attempt to post the link: https://github.com/python/

[issue36139] release GIL on mmap dealloc

STINNER Victor added the comment: The bug: https://github.com/python/cpython/pull/12073/files#r263026496 (correct link, sorry) -- If nobody comes up quickly with a fix, I will revert the change to repair Windows buildbots: PR 12198, as part of the buildbot policy ("revert on failure"). I do

[issue36139] release GIL on mmap dealloc

Change by STINNER Victor : -- pull_requests: +12193 stage: resolved -> patch review ___ Python tracker ___ ___ Python-bugs-list mail

[issue36139] release GIL on mmap dealloc

STINNER Victor added the comment: The bug: https://github.com/python/cpython/pull/12073/files#r263026496 -- ___ Python tracker ___

[issue36139] release GIL on mmap dealloc

STINNER Victor added the comment: This change broke the Windows 7 buildbot: https://buildbot.python.org/all/#/builders/40/builds/1745 Example: 0:01:34 [ 66/420/1] test_mmap crashed (Exit code 2147483651) -- running: test_tools (1 min 22 sec) Fatal Python error: Python memory allocator called

[issue36139] release GIL on mmap dealloc

Benjamin Peterson added the comment: New changeset bb9593af0ac835b93c2834d44b72fa34e30efed0 by Benjamin Peterson (Davide Rizzo) in branch 'master': closes bpo-36139: release GIL around munmap(). (GH-12073) https://github.com/python/cpython/commit/bb9593af0ac835b93c2834d44b72fa34e30efed0 ---

[issue36139] release GIL on mmap dealloc

Christian Heimes added the comment: The change sounds like a good idea and should be backported, too. IIRC mmap() performance also depends on MMU and TLB speed. In the past I have seen paravirtualized systems with poor MMU performance that caused fork() to be slow and Redis to hang. ---

[issue36139] release GIL on mmap dealloc

Davide Rizzo added the comment: munmap() of private maps is usually pretty fast but not negligible (2 ms for 1GB). Shared maps are much slower. For some reason, shared maps explicitly backed by POSIX shared memory stand in between but are still pretty slow. If someone cares about file-backed

[issue36139] release GIL on mmap dealloc

Davide Rizzo added the comment: Yes, this is mmap module. I found this to be slow for posix-shm-backed mmaps. Several milliseconds, like 20ms for a 128 MB object. Maybe the same can happen with private|anon mmaps? I will follow up with more numbers. -- __

[issue36139] release GIL on mmap dealloc

Inada Naoki added the comment: Sorry, I messed up. Your PR is changing mmap module, not obmalloc. -- ___ Python tracker ___ ___ Py

[issue36139] release GIL on mmap dealloc

Inada Naoki added the comment: Your patch is modifying obmalloc. It uses MAP_PRIVATE|MAP_ANONYMOUS mmap. Does it really take log time? How? #1572968 is different. It is mmap module. It can use file-backed mmap. It is I/O. -- nosy: +inada.naoki ___

[issue36139] release GIL on mmap dealloc

Change by Roundup Robot : -- keywords: +patch pull_requests: +12092 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-l

[issue36139] release GIL on mmap dealloc

New submission from Davide Rizzo : munmap() can take a long time. I think mmap_object_dealloc can trivially release the GIL around this operation. Something similar was already mentioned in https://bugs.python.org/issue1572968 but a general patch was never provided. The dealloc case alone is