Message133741
| 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??? |
|