[issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD)
Steffen Daode Nurpmeso
report at bugs.python.org
Thu Apr 14 16:16:57 CEST 2011
Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:
Pfff.
Now i really spent some time on Mac OS X memory management.
I did it for Wanda. :)
(First: i don't know why you want to drop that nice mmap(2),
it's wonderful to test harddisk performance!
And if you want to support Apple, then you have to spend
some blood - right???
Implement a state machine, disallow mmap(2) if the file has
been written to. Maybe i should spend some more hours and
try to find rules behind this??)
Situation is a follows.
Also here there are some nice sysctl(8) variables:
hw.memsize: 2147483648
hw.usermem = 1651843072
vm.global_no_user_wire_amount: 67108864
vm.global_user_wire_limit: 1811939328
vm.user_wire_limit: 1811939328
That doesn't mean much though.
I've searched Apples developer pages with their unbelievable
stupid search engine and found
developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/About/About.html
I've downloaded that as a PDF (upper right corner).
That doesn't mean much though.
So i finally did some tests using Nadeem's code snippet
from msg133677. The largest top(1) i ever got was
30477 python3 2.7 00:09.77 1 0 18 77 912M+ 240K
but the system is unusable then.
I killed all tests which spent more than about three minutes first,
later i did so whenever 900M was not reached in top(1) output -
it seems to me that Apple's VM is not intelligent enough to detect
that it effectively has entered an endless loop!!!
The result of all that is that i think i can savely give you the
following advice for my MacBook (Mac OS X 10.6.7, but uname 10.7):
x = bytearray(hw.usermem=1651843072 // 2)
responses in few fractions of a second almost regardless of system
load and gives that top(1) line:
31369 python3 0.0 00:01.29 1 0 18 71 794M 240K
x = bytearray(hw.user_wire_limit=1811939328 // 2)
responses in noticably more fractions of a second and gives the
following top(1) line:
32899 python3 0.0 00:01.39 1 0 18 71 870M 240K
Note that the system seemed to handle the first case somewhat
easily, whereas the latter resulted in unresponsive window
switching etc. etc., so that it seems as if...
I don't know wether Python offers the available memory size values
somewhere, but note that Apple has moved sysctl(8) from /sbin
to /usr/sbin, which is a lie if you would ask me to express my
opinion.
Except for all this i don't understand this thread.
Isn't that bot the one for which haypo has noticed those
random failures???
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
More information about the Python-bugs-list
mailing list