Gunnar Vestergaard <post@gunnar-v.dk> wrote:
> Nu har jeg brug for at vide en ting: Er det ikke muligt i OS X selv at
> styre hvilken prioritet de enkelte programmer skal have? Jeg går ud fra
> at OS X har preemptiv multitasking. For i så fald vil du kunne få Word
> til at fungere som en drøm, selv om du samtidig har et program til at
> rendere en tegnefilm af spillefilmslængde.
klippet fra:
<
http://arstechnica.com/reviews/01q4/macosx-10.1/macosx-10.1-8.html>
Priority Control
Priority control, the mechanism through which certain processes are
given more or less opportunity to use CPU cycles, was badly broken in
Mac OS X 10.0.x. This problem was quite easily demonstrated in 10.0.x
using a simple "spin test" (a program with an infinite loop) and the
Unix nice command (used to set process priority from the command line),
as the following (slightly abridged) 10.0.4 terminal session shows:
# cat > spin.c
main(){for(;;);}
# cc spin.c -o spin
# nice -20 spin &; nice +20 spin &
[1] 442
[2] 443
# alias psn "ps -o'pid,nice,time,%cpu,command'"
# psn -p442; psn -p443
PID NI TIME %CPU COMMAND
442 -20 1:41.65 43.8 spin
443 20 1:41.45 49.0 spin
As you can see, both processes got comparable amounts of CPU time,
despite being at the far ends of the priority spectrum (20 is the lowest
priority level, and -20 is the highest).
In 10.1, priority control via nice now works correctly:
# cat > spin.c
main(){for(;;);}
# cc spin.c -o spin
# nice -20 spin &; nice +20 spin &
[1] 334
[2] 335
# alias psn "ps -o'pid,nice,time,%cpu,command'"
# psn -334; psn -335
PID NI TIME %CPU COMMAND
334 -20 2:08.11 65.6 spin
335 20 1:36.67 22.8 spin
The high priority process now (correctly) gets more opportunities to use
CPU cycles than the low priority process.
Given the impressive performance of iTunes in 10.1, I wondered if it was
taking advantage of 10.1's newly-functional priority control. But the
iTunes process in 10.1 appears to run at the same priority (0, half way
between -20 and 20) as every other normal user process in 10.1.
Additionally, only the superuser (a.k.a. root) may increase a process's
priority. Normal users may only lower the priority of their processes.
Mac OS X reportedly has some support for real-time priorities--that is,
priorities that guarantee a certain amount of CPU cycles per unit time.
Is iTunes using one or more real-time threads to maintain skip-free
music playback? I'm not sure, but I did try changing its priority via
the renice command, with some strange results.
iTunes starts at the standard user priority level (0), and is basically
unskippable in this state. The only way I could upset it was by running
a "memory bomb" (a process that allocates memory in an infinite loop) as
the superuser--and it allocated over 600MB of memory on the 384MB G3
before iTunes started to stutter.
Decreasing the priority to 10 (remember that higher numbers correspond
to lower priorities) made iTunes eminently susceptible to the old
transparent-Terminal-shaking test: skip city.
The strangeness occurred when I increased the priority (as root) back to
its original level of zero. Rather than returning to its former
skip-free glory, iTunes remained susceptible to skip-inducing actions.
I'm not quite sure what's going on here. If there were any real-time
threads running in iTunes, renice seems to have brought them back down
into the realm of normal priority levels. And they didn't restore
themselves when iTunes was reset to its original priority. (If anyone
knows what's going on here, please mail me)
Anyway, this is all somewhat academic. The bottom line is that iTunes,
in its normal state, is virtually indestructible. And the
newly-functional priority control will certainly being useful for Unix
hackers and Apple's own core OS team alike.
--
Venlig hilsen Morten Reippuert Knudsen... snart på iceBook, igen
<icq:131382336> <Marianne Jelved = Gud>