Re: scheduling question
Re: scheduling question
- Subject: Re: scheduling question
- From: Stefan Werner <email@hidden>
- Date: Thu, 15 Jan 2004 10:31:57 +0100
Hi,
On Wednesday, Jan 14, 2004, at 22:05 Europe/Berlin, Jim Magee wrote:
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.
Are there other tweaks to enhance the latency of networking? I don't
mind a decrease in throughput, I'm in one of the rare cases where
bandwidth is not the limit. There are these popular "bandwidth tuner"
tweaks where people change the system's TCP buffer size with sysctls,
would shrinking the buffers give me any latency improvements or will
that result in dropped packets?
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.
So, using THREAD_PRECEDENCE_POLICY will only increase the priority of
the thread within my process, but the priority of my thread will not be
affected? If so, increasing the process' priority in addition should
then give me the desired system-wide effect, I assume.
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.
I think that's what one of the code snippets I tried is doing. I got
that from someone on the CoreAudio list when I asked for low-latency
scheduling tips.
One more question: If I change a thread's scheduling policy, will
threads created from that one inherit that policy or will they have
normal policy?
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).
The main competitor for my network thread is a CoreAudio thread with a
number of processing-intensive AudioUnits. Well, it could be that some
of the problems I have now on my development iBook disappear by
themselves when we run it on the dual G5 it's intended to run on.
-Stefan
_______________________________________________
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.