Re: More thread scheduling observations
Re: More thread scheduling observations
- Subject: Re: More thread scheduling observations
- From: Ian Ollmann <email@hidden>
- Date: Sun, 5 May 2002 09:39:52 -0700
On Sun, 5 May 2002, Kurt Revis wrote:
>
On Saturday, May 4, 2002, at 11:40 PM, Ian Ollmann wrote:
>
>
> Why dont you give this a try: Turn timesharing off so that you are
>
> scheduled in a round robin fashion, among threads of equal priority. If
>
> you set your priority equal to the window server, you should get the CPU
>
> as often as the window server does.
>
>
This works quite well, thanks! Turning importance up to 64 helped a
>
lot, but I could still get dropouts. Turning off timeshare as well makes
>
it really reliable--I can't get dropouts at all, even when the buffer
>
between my feeder thread and the audio IO thread is quite small.
Great! I am glad it worked.
Now, here is the problem. If we have everyone scheduling themselves at PRI
64 with timesharing off, we will end up with an arms race and nobody will
get the dependability they want. So, if you do this, your responsibility
is to make sure that you *really* *REALLY* need priority 64 and
furthermore you MUST not hog the CPU. As I mentioned earlier, the window
server worker thread is at a lower priority. At PRI=64, you are competing
with things like event dispatching to applications (which the window
server also handles), which is not really a good thing to do. Your app
could damage the responsiveness of the entire system at this level. This
is not an idle threat. There are such things as thread punishers in the
kernel that deprive threads of their privileged status and send them to
priority 0 if they abuse these privileges.
So, let me briefly explain what timesharing does in an effort to convince
you that you do not need PRI=64, even though you may think you do. A
standard thread has timesharing mode on. If you overuse the CPU with
timeshare mode on, the kernel thread scheduler (as much as there can be
said to be such a thing) will reduce a threads priority. This process can
continue until you hit priority 0 and only get CPU time when nobody else
needs it. This is a good thing, because it allows considerate threads to
get the time when they need it (their priority stays high) and CPU hogs
get demoted to the point where they no longer damage the responsiveness of
the system. Because they only have considerate threads above them, CPU
hogs will not lose much of the CPU due to this process, but other threads
will be able to get time when they need it.
A problem happens for threads that have real time constraints, such as
audio -- threads that fail entirely unless they always get CPU time when
they need it. This is because there will be times when a timeshare thread
may have a very low priority and such threads may not get the CPU for
milliseconds at a time. Elevating your threads priority with timesharing
on did not completely fix this problem because it still spends some of its
time at a low priority. That is likely when the audio dropouts were
occurring.
When you turn timeshare mode off, your thread assumes a fixed priority. It
will never go down. Threads at the same priority are scheduled in a round
robin fashion with each other. This means that if a priority level of 55
is sufficient to guarantee that you get the time you need, scheduling
yourself at priority 64 does nothing but damage the responsiveness of the
system. Furthermore, a lower priority means that you are less likely to
experience a priority inversion, in which some OS service that you depend
on for your high priority thread to function is scheduled at a lower
priority than your thread.
So to make a long story short, do not simply elevate your thread to
timeshare off and PRI=64. Turn timeshare off then see how low priority you
can go before the interruptions start again. This will leave some
breathing room for you and other people to schedule things properly and
will help prevent the performance of your thread from suffering from a
priority inversion. You MUST release the CPU regularly and frequently, if
you turn timesharing off. You must be able to rely on other people who
pursue this strategy to do likewise. Anything less will damage the
responsiveness of the system, and ruin its utility for you.
More privileges come with greater reponsibility.
Ian Ollmann
---------------------------------------------------
Ian Ollmann, Ph.D. email@hidden
---------------------------------------------------
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.