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

Jonas Maebe jonas.maebe at ugent.be
Mon Aug 9 15:22:13 EDT 2004

On 9 aug 2004, at 19:58, Elektron wrote:

> FreeBSD did scheduling properly. Mac OS X's scheduler is icky,

Mac OS X' scheduler not based on FreeBSD's. Apple uses FreeBSD as the 
traditional Unix interface to the kernel, but most of the lowest level 
stuff does not come from FreeBSD at all.

> and though it supports nice 20, still manages to screw up scheduling 
> (and top doesn't show the priority). When more processes are 
> competing, it seems to do it better.

It simply depends on your design goals I guess. When I reported that 
nice level 20 did something different than only consuming idle time, my 
bug report was closed as "behaves correctly".

Mac OS X has many more priority levels than the traditional -19..20 
(and indeed different classes of priorities), and the system is mainly 
built for low latencies (which are still quite remarkable compared to 
most other systems out there afaik, including Linux and FreeBSD) and 
giving consistent/guaranteed maximum latencies under heavy load, than 
getting optimal performance in all cases.

>  5293 lag         25.4%  0:04.45   1    11    20   104K   392K   372K  
> 26.7M
>  5291 lag         25.3%  0:04.45   1    11    20   104K   392K   372K  
> 26.7M
>  5292 lag         25.2%  0:04.39   1    11    20   104K   392K   372K  
> 26.7M
>  5279 lag         16.4%  1:54.28   1    11    21   104K   392K   372K  
> 26.7M
> I'm also not sure why a a one-liner allocates 26 megs of VM

man vmmap

> (OSX's memory management is horrible).

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.

If it bothers you, you can decrease it by passing something like 
"-Xlinker -stack_size -Xlinker 2000" to gcc (stack size = hexadecimal). 
The stack doesn't seem to grow automatically however (though you can up 
it to the current hard limit with setrlimit()), which is not so nice 
and which explains the large default.

Keep however in mind that smallish command line apps like that form a 
minority of the apps started a typical OS X system, and that the system 
defaults are most likely optimized towards the other extreme (large GUI 
apps using tons of dynamic libraries).


More information about the rc5 mailing list