scheduler (sched_4bsd) questions
julian at elischer.org
Sun Oct 3 00:04:57 PDT 2004
Stephan Uphoff wrote:
> On Sat, 2004-10-02 at 14:31, Peter Holm wrote:
>>OK, right now I'm testing with all of Stephan's patches + the
>>MUTEX_WAKE_ALL flag. Uptime is 3 3/4 hour and looking good.
> Your attached diff contained all the fixes needed and I don't see the
> need to post a cumulative patch.
> The only thing left to do is migrate a critical sections from
> kern_mutex.c to subr_turnstile.c for readability.
> (no functional changes)
> Maybe it would also better to just force MUTEX_WAKE_ALL in
> kern_mutex.c (#ifndef MUTEX_WAKE_ALL \n#define MUTEX_WAKE_ALL\n#endif)
> to avoid temporary configuration file pollution?
Just reading your patch(es)..
What's the logic behind adding the critical sections around the
priority changes in the turnstyle code?
can you give an example of the timeline you are avoidning?
I presume it involves an interrupt setting another thread running.
Why do you think that it is unacceptible to allow a thread with a lower
priority to continue to run on another cpu (or this cpu) (maybe_preempt_in_ksegrp())
Can you show the reason that this is "critical" and not just suboptimal?
If you are going to preempt threads from the same KSEGRP why not preempt
threads from other ksegrps? BTW an available slot count going
-ve might not be a disaster.. it's just a count..
I guess you must have KSEG_PEEMPT_BEST_CPU always set because
preempting the "not best" cpu would lead to teh same inversion problem
that you are trying to avoid, when you leave a thread running on another CPU
that has less priority (numerically greater than) than the one that you
Where is the critical_enter that matches the extra critical_exit()
you put in sched_switch()? I haven' been able to yet figure out how
you don't get a double exit. but I've only looked for a few minutes.
regarding the ksegrp runq.
For some time I have wanted to split it into 3 queues and the
threads will move between them. (in the ksegrp sched-private section)
queue 1.. threads that are running
queue 2.. threads that are on the system run queue.
queue 3.. threads that do not yet have a slot.
what do you think?
it should simplify the slot counting stuff.
More information about the freebsd-arch