Re: scheduling question
Re: scheduling question
- Subject: Re: scheduling question
- From: Jim Magee <email@hidden>
- Date: Wed, 14 Jan 2004 16:05:39 -0500
On Jan 14, 2004, at 1:35 PM, Stefan Werner wrote:
I am writing a real-time application and am in the optimization phase
right
now, playing with priorities and scheduling parameters. The critical
thread
in my application is a loop around recv() that is waiting for UDP
packages
and processes them upon reception. It should react on incoming
packages as
quickly as possible and get the processing done in a certain time. Now
I'm
wondering what's better suited for my thread: Real-time scheduling
(guaranteeing my thread a certain time slice) or a "regular" thread
with an
insanely high priority? I tried some code snippets I found, one of
them* is
setting my thread to THREAD_TIME_CONSTRAINT_POLICY, the other is
setting it
to THREAD_PRECEDENCE_POLICY, in addition to setting
threadExtendedPolicy.timeshare = 0. I tried them both, and with each
of them
my application performed much better than with standard threading. But
still, it could be a tad better, and I guess I should start tweaking
the
parameters I pass to the functions. Before I spend too much time doing
that,
I wonder what will give me better results: time constraint or
precedence
policy? Will changing the process' priority improve anything or are my
threads scheduled independently of the process?
Handling network traffic in a realtime (as defined by
THREAD_TIME_CONSTRAINT_POLICY) thread doesn't mix too well. Those
threads are meant mostly for talking directly to external devices that
can There are "helper" threads that process the data within the
in-kernel network code somewhat isolating your thread from directly
accessing the network hardware in that way. Your realtime thread may
even interfere with the responsiveness of these helper threads in ways
that might affect your own data. Even if you don't interfere with the
processing of the in-kernel data, your response-time characteristics
are going to be dominated by the scheduling behavior of these in-kernel
threads. There are also situation where the network stack just borrows
another user-level thread (that just happened to be in the network
stack at the time) to drive completion of your packet handling (inbound
and outbound). Obviously, you can't make these all realtime threads,
so that too will affect your latency. For these reasons it is probably
counter-productive to go all the way to a TIME_CONSTRAINT thread for
this kind of data handling.
The THREAD_PRECEDENCE_POLICY isn't really a completely different policy
from the normal timeshare (migrating priority) policy on the system.
It's just a way to control a key aspect of that policy. In essence,
you are telling the schedule that, within this one process, some
threads should have precedence over others even if they have the same
priority. Essentially, you are assigning ordinal values to the process'
threads without having to know or guess an appropriate system-wide
priority for the threads. The system doesn't guarantee to honor it,
but will attempt to do so (fairness may dictate that we chose threads
to execute out of ordinal order). However, the effect should be
process-local, and therefore cannot be relied upon to have any
system-wide effect whatsoever.
What has worked well for others in this type of situation is to use the
THREAD_EXTENDED_POLICY notion to declare the thread as a
"non-long-running" thread (by specifying the timeshare parameter as
FALSE). As long as your thread is well behaved and gives up the CPU in
reasonable amounts of time, it will always run at a fixed priority. As
such, it will have significant preference over other threads in the
system that are (or have been) consuming large amounts of CPU time (and
are therefore likely to get in the time way of reasonable timeliness).
--Jim
_______________________________________________
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.