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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.