Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Jeff Moore <email@hidden>
- Date: Thu, 1 Apr 2004 11:39:04 -0800
Sorry. I can't point to a specific file or something like that for you
to look at. I get most of my knowledge either by talking to the kernel
guys about it, from experimental evidence gleaned over the years of
working with the HAL's IO thread and from looking at the kernel traces
that get produced when things go astray.
If you really want to get down into the nitty gritty of how the
scheduler works at the code level, you should probably post your
questions to the Darwin-Dev mailing list. I think all the appropriate
folks who should be able to answer your questions monitor that list.
On the other hand, if you are trying to do something specific, you
should probably describe it and we can probably give you some good
advice as to how best to accomplish it.
On Apr 1, 2004, at 12:44 AM, Stiphane Letz wrote:
Message: 5
From: Jeff Moore <email@hidden>
Subject: Re: Audio threads scheduling
Date: Wed, 31 Mar 2004 18:50:45 -0800
To: CoreAudio API <email@hidden>
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:
Thanks.
I tried to looked at the Darwin source (actually in XNU-517.3.15),
found something about the use of the "constraint" parameter , but
nothing about the use of the"computation" parameter. Are the source
you're referring to in Darwin? Or in the IOKit?
Do you have any references?
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.