RE: problem with real-time scheduling
RE: problem with real-time scheduling
- Subject: RE: problem with real-time scheduling
- From: "Michelle Munson" <email@hidden>
- Date: Thu, 22 Jul 2004 18:12:51 -0700
Jim,
Thank you very much for the thorough response. Admittedly I was surprised to
learn that the thread_time_constraint_policy settings aren't really
implemented; it explains why changing the values didn't alter the behavior.
As a first cut, I think I will experiment with using the
THREAD_EXTENDED_POLICY and setting info->timeshare FALSE. I haven't been
able to locate any reference in the API docs to THREAD_EXTENDED_POLICY. Is
this documented somewhere?
-Michelle
-----Original Message-----
From: email@hidden
[
mailto:email@hidden]On Behalf Of Jim Magee
Sent: Thursday, July 22, 2004 4:18 PM
To: Michelle Munson
Cc: email@hidden
Subject: Re: problem with real-time scheduling
On Jul 22, 2004, at 5:01 PM, Michelle Munson wrote:
>
Using the real-time API for the Mach kernel
>
(set_thread_priority(...)), we
>
are able to guarantee our application thread enough of the CPU to run
>
fairly
>
smoothly even when another process is competing. However, now the
>
behavior
>
we observe is that when our process has run smoothly for a while at
>
high CPU
>
usage (approx 70-80% for example), it will be suddenly "demoted" by the
>
scheduler to a very low CPU%. Piecing together background from the
>
kernel
>
programming documentation on Apple's developer site, I believe that
>
this
>
"demotion" effect happens because the scheduler automatically demotes
>
processes deemed to be taking too much of the CPU.
>
>
What's surprising is that we are using "reasonable"
>
thread_time_constraint_policy settings. We have experimented with a
>
range of
>
values based on examples from Apple and other "real-time" applications
>
such
>
as audio and video players. We are taking a high but still reasonable
>
percentage of the CPU.
It doesn't matter what you set for the scheduler settings. Unless you
explicitly block or yield the CPU, the scheduler doesn't know that you
haven't just overrun your defined computation and need more time to
complete. So, it gives it to you (in fact, besides some sanity checks,
those values are ignored in the current implementation of the scheduler
- but will be used at some future date). It is your
application/thread's behavior, and not its "supposed to work this way"
scheduler definition - that determines whether it is hogging the CPU
(today, that's defined as running for 8 seconds in realtime mode
without ever once yielding the CPU away or blocking).
>
So the basic question is, is there a way that we can guarantee that our
>
process will not be completely stopped when competing processes launch
>
other
>
than using the real-time API? And if we need to use the real-time API,
>
is
>
there a way we can avoid the demotion effect, for example, yield to
>
other
>
processes when necessary?
Because your thread is consuming tons of CPU time - and is running
under a timeshare (priority adjusting) policy - it probably is
degrading to just above an idle thread by the time the other process
launches. It's no wonder it is then taking a big chunk of the CPU away
from you - before the scheduler finally adjusts you back up to where
you can fairly compete for the CPU.
The method used to yield the CPU from time to time (and avoid losing
your time-constraint policy setting) depends upon the programming mode
of the application. If it is Carbon, WaitNextEvent(), or better yet,
going back to the runloop does the trick (the latter works for Cocoa
too). Using usleep() or select() from a Unix application will also do
it.
If you can't yield any time explicitly (or go back to the runloop), you
can take the timeshare (adjusting priority) nature of your process away
without boosting it into higher priorities of time-constrained threads.
The typical solution is to use
thread_policy_set(THREAD_EXTENDED_POLICY) setting the info->timeshare
to FALSE. In addition, we have found the setting your priority lower
by just a few notches helps when doing this. It allows a timeslice or
two for other processes before they degrade below your priority -
giving reasonable response time for them and relatively low latency for
you (since you will always be near the top of the priority scale for
"normal threads - and they don't stay at the top for very long if they
are timeshare).
--Jim
[demime 0.98b removed an attachment of type application/pkcs7-signature
which had a name of smime.p7s]
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.