Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Jeff Moore <email@hidden>
- Date: Wed, 31 Mar 2004 18:50:45 -0800
First off, I want to preface this by noting that the behavior of the
scheduler is mostly only documented by the code in Darwin. My comments
here are based on my understanding of how things work currently and how
the HAL does things. Things do change from time to time, so I would not
write code that depends on things working in any particular way.
That said, the documentation is correct but I think you misunderstand
what these numbers are used for by the scheduler. I'll try to break
things down a little more.
The period basically says how often the real time thread wants to wake
up. In HAL terms, it is the length of the IO cycle.
If the thread is marked as pre-emptible, the computation value
indicates for how long after the start of a new cycle the thread can't
be pre-empted. When the scheduler is first transitioning tot he new
thread, it will set the decremeneter for this length. When the
decrementer fires, it checks if there are any other real time threads
that need to run and will then round robin with them. If there aren't
any other threads to run, the scheduler sets the decrementer for this
amount of time so it can check again later. Note that if you set the
computation value equal to the period, you are saying that your thread
is effectively not pre-emptible. Like I said, the HAL uses this value
to allow for some prioritization between the various IO cycle lengths
in different processes.
The constraint value indicates the amount of time the thread can run
before it is considered a "miscreant". If a thread is a miscreant, it
faces penalties even if it is marked as not being pre-emptible. The
first penalty a miscreant faces is pre-emption as the scheduler will
have the decrementer fire to enforce this. Secondary penalties include
gradual slippage in priority. For the HAL, going beyond the length of
the IO cycle is catastrophic, so it sets the constraint to be equal to
the period.
Hope this helps.
On Mar 31, 2004, at 5:51 PM, Stiphane LETZ wrote:
--__--__--
Message: 4
From: Jeff Moore <email@hidden>
Subject: Re: Audio threads scheduling
Date: Wed, 31 Mar 2004 12:14:03 -0800
To: CoreAudio API <email@hidden>
One last thing, I should caution that the parameters the HAL uses for
scheduling it's IO threads can and will change in the future as the
system evolves and we learn more about it. In other words, I wouldn't
write code that depends on this stuff working this way.
On Mar 31, 2004, at 12:10 PM, Jeff Moore wrote:
The computation value indicates the initial period for which the
thread will not be pre-emptible. I believe that this is implemented
in
scheduler by when it sets the decrementer interrupt to next go off.
The HAL chooses the value for this parameter so that shorter IO
cycles
get more time to not be pre-emptible and longer cycles become
pre-emptible sooner. This, in effect, prioritizes the shorter cycle
over the longer cycle.
This prevents a priority inversion that can occur when there are
cycles with both large and small durations in which the IOProcs are
using reasonable CPU loads. For instance if both Process A and
Process
B are using 25% CPU load in their respective IOProcs, but A's cycle
is
4000 frames long and B's cycle is 100 frames long. If A's cycle
didn't
become pre-emptible quickly enough, it would easily cause B to miss
many of it's cycles, even though both processes are using reasonable
CPU loads.
It also encourages IOProcs to execute faster so the thread can go
back
to sleep as this is less likely to get pre-empted.
On Mar 31, 2004, at 1:10 AM, Stiphane Letz wrote:
That was not what I was understanding reading the documentation for
THREAD_TIME_CONSTRAINT_POLICY :
Parameters:
period: This is the nominal amount of time between separate
processing arrivals, specified in absolute time units. A
value of 0 indicates that there is no inherent periodicity in
the computation.
computation: This is the nominal amount of computation
time needed during a separate processing arrival, specified
in absolute time units.
constraint: This is the maximum amount of real time that
may elapse from the start of a separate processing arrival
to the end of computation for logically correct functioning,
specified in absolute time units. Must be (>= computation).
Note that latency = (constraint - computation).
preemptible: This indicates that the computation may be
interrupted, subject to the constraint specified above.
I was thinking that as soon as the thread is marked *preemptible*, then
the scheduler is free to divide up the "computation" duration into
several slices in order to meet the deadline of all threads, in
particular when the threads don't have the same period.
There is nothing said in the doc about the relationships between the
"computation" parameter and the thread preemptibility.... Or the
documentation is not correct?
Thanks
Stephane Letz
_______________________________________________
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.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.