[RC5] Re: Needing testers (Mac OS X/G5)
jonas.maebe at ugent.be
Tue Aug 10 03:31:41 EDT 2004
On 9 aug 2004, at 22:07, Elektron wrote:
> ps (and top) take up far too much cpu time for me to believe it's
> supposed to involve 'low latencies'.
You are confusing high performance and low latency. Latency has nothing
to do with how long something takes. Latency has to do with how long it
takes for your process to get the cpu after some timer expires or an
> top takes up 5% of a p133 running some old version of redhat, but 10%
> of a G4/700 (and I'm not running that many more processes).
Use top -d if you want top to consume less cpu time (and also add -s 3
if you want to compare with an old Red Hat, where top afaik only
updates every 3 seconds). Walking the mach vm maps does take a lot of
time. And again, this has absolutely nothing to do with latency.
> Each process isn't even guaranteed the 10000 microsecond timeslice of
> cpu time (which is easy enough to check by monitoring the TB), the
> median is 1200 on heavy load. The highest is only 8200. If I allow for
> gaps of 1% of the timeslice, the median is still 3400 (though the
> highest is 15000).
This probably has to do with latency optimizations. You can't have both
low latency and give everyone always a full time slice.
>> It has little to do with bad memory management by the OS. If you
>> check the output from vmmap, you'll see there's 16MB malloc'ed (but
>> otherwise largely unused) memory that forms a large part of that
>> memory. There's also an 8MB stack though, which is quite large.
> I know it's allocated and untouched, but that doesn't make OSX's
> memory management any less horrible.
I simply wanted to point out that the large virtual size has nothing to
do with the memory management of the OS, it's simply allocated
somewhere in the startup code of libc or so.
> OSX's file cache is worse than windows' - the time I accidentally
> turned VM off, everything ran faster (maybe I should try this again).I
> shouldn't need to set F_NOCACHE so that checksumming disk images
> doesn't take forever because it has to page out, or lag everything
> afterwards because things have to be paged in.
VM implementations always have stronger and weaker points. There is no
known VM strategy that performs optimally in all cases. That's exactly
why there are interfaces like madvise etc.
OS X pro-actively swaps out stuff, so there is less chance for
thrashing storms when a program suddenly needs a lot of memory. Linux
waits with swapping until there is no memory left, so the system is
zippier until your run out of memory. It's mainly trade-offs.
That does say OS X's implementations of everything is the best of breed
of course (if only because they've been able to improve the overall
speed with every release until now).
> Then there's other quirks, like the incorrect format strings in
Yes, that's a bug I also encountered, but I can't see why on earth that
bug would indicate a general quirkiness of the system.
But this is all wildly off topic for this list, so next time I'll reply
More information about the rc5