[RC5] Re: Needing testers (Mac OS X/G5)

Jonas Maebe 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 
interrupt/signal occurs.

> 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 
> hotfiles_evict

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 
in private.


More information about the rc5 mailing list