homepage

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 sdaoden
Recipients ixokai, nadeem.vawda, ned.deily, neologix, pitrou, sdaoden, skrah, vstinner
Date 2011年04月14日.14:16:55
SpamBayes Score 2.9120872e-11
Marked as misclassified No
Message-id <1302790617.52.0.308908133547.issue11277@psf.upfronthosting.co.za>
In-reply-to
Content
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???
History
Date User Action Args
2011年04月14日 14:16:57sdaodensetrecipients: + sdaoden, ixokai, pitrou, vstinner, nadeem.vawda, ned.deily, skrah, neologix
2011年04月14日 14:16:57sdaodensetmessageid: <1302790617.52.0.308908133547.issue11277@psf.upfronthosting.co.za>
2011年04月14日 14:16:56sdaodenlinkissue11277 messages
2011年04月14日 14:16:55sdaodencreate

AltStyle によって変換されたページ (->オリジナル) /