Re: Yielding the processor in a kext?
Re: Yielding the processor in a kext?
- Subject: Re: Yielding the processor in a kext?
- From: Terry Lambert <email@hidden>
- Date: Fri, 7 Sep 2007 19:58:07 -0700
On Sep 7, 2007, at 10:10 AM, Régis Duchesne wrote:
Michael,
1) When a long-running task is being performed at an inappropriate
priority, and it might be "nice" to let other threads have the CPU.
In this case, I argue that the task should simply be moved to
another thread that runs at an appropriate priority.
So let's say I realize that one of my threads is too far ahead of the
others in its computation. I want to slow it down, so I'll reduce its
priority.
Now imagine that 2 different users start 2 different instances of
the app:
o User A starts the app with 2 threads TA1 and TA2, and this scenario
occurs, TA1 is way ahead of TA2, so TA1 lowers is priority.
o User B starts the app with only 1 thread TB.
At this point, user A loses: TA1 will almost never be scheduled
anymore,
because TB will always have a higher priority.
This is only true if your thread priority is PTHREAD_SCOPE_SYSTEM,
rather than PTHREAD_SCOPE_PROCESS, and therefore each of the threads
in your process compete on an equal footing with every process in the
system.
In your example above, you want your processes to compete equally as
units, irrespective of number of threads, so your use is inapprpriate;
I suggest you look at adding a pthread_attr_t with process scoping for
scheduling.
I really want to lower the priority of my thread _within_ its task
(because the scheduling of that thread relative to the other in the
same
task is a decision that can be best made by my app). But the APIs
that I
find only allow me to do it system-wide.
This is not exatly what you are saying here, if I am interpreting
"will almost never be scheduled" as a complaint about the scope value
for your competing for quantum.
So as a workaround, I want a way to yield the processor, i.e. go at
the
end of the scheduling queue but with the exact same priority.
This is a hack; there are many different ways you could avoid this
hack, almost all of which are a better fit for the problem of geting
process-scope "fair share" while keeping SMP scalability.
Realize also that User A is always going to get more quanta on an SMP
system because their implementation is not SMP scalable; it's
impossible to guarantee fairness in this situation without hitting
user B in the head with a shovel and telling them to use the sysctl's
to find out how many threads they should be starting, instead of the
incorred number they are.
-- Terry _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden