[RC5] Re: Needing testers (Mac OS X/G5)
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.
> PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE
> 5293 lag 25.4% 0:04.45 1 11 20 104K 392K 372K
> 5291 lag 25.3% 0:04.45 1 11 20 104K 392K 372K
> 5292 lag 25.2% 0:04.39 1 11 20 104K 392K 372K
> 5279 lag 16.4% 1:54.28 1 11 21 104K 392K 372K
> I'm also not sure why a a one-liner allocates 26 megs of VM
> (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