Re: More thread scheduling observations
Re: More thread scheduling observations
- Subject: Re: More thread scheduling observations
- From: Bill Stewart <email@hidden>
- Date: Sun, 05 May 2002 14:26:07 -0700
An arms race is not a good idea...
And we understand that some of the reasons for doing this are because of
system services that you can't get out of the way. But, this has been fixed
in Jaguar - as a result of this we will be changing some of our own
priorities, and making recommendations to developers about the priorities
they use. This will be covered at WWDC - I don't feel I should pre-empt (pun
intended, sigh!) that presentation, so I'll make sure we give out a summary
after the event.
Ian's comments are very appro pro here...
Bill
on 5/5/02 9:39 AM, Ian Ollmann wrote:
>
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.
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"Thousands of years ago, cats were worshipped as gods. We have never
forgotten this."
__________________________________________________________________________
_______________________________________________
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.