Date: Tue, 29 Dec 1998 08:43:05 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: hackers@FreeBSD.ORG Subject: maybe_resched() -- Help me understand it? Message-ID: <19981229084305.A502@tar.com>
next in thread | raw e-mail | index | archive | help
I've been trying to understand the various scheduling calls (rtprio,
setpriority, sched_setscheduler, sched_setparam, etc) and I'm
having trouble. I can't decide if there are bugs, or if I
just don't understand it all. Rather than post all my questions
at once, I'll start with my questions about maybe_resched.
I'd really appreciate someone looking at this to see if its
just that I don't understand whats happening here. maybe_resched
is defined like this (its in kern_synch.c):
/* maybe_resched: Decide if you need to reschedule or not
* taking the priorities and schedulers into account.
*/
static void maybe_resched(struct proc *chk)
{
struct proc *p = curproc; /* XXX */
/*
* Compare priorities if the new process is on the same scheduler,
* otherwise the one on the more realtimeish scheduler wins.
*
* XXX idle scheduler still broken because proccess stays on idle
* scheduler during waits (such as when getting FS locks). If a
* standard process becomes runaway cpu-bound, the system can lockup
* due to idle-scheduler processes in wakeup never getting any cpu.
*/
if (p == 0 ||
(chk->p_priority < curpriority &&
RTP_PRIO_BASE(p->p_rtprio.type) ==
RTP_PRIO_BASE(chk->p_rtprio.type)) ||
RTP_PRIO_BASE(chk->p_rtprio.type) < RTP_PRIO_BASE(p->p_rtprio.type)) {
need_resched();
}
}
What I don't understand is this:
1) If chk is the current process, I would think you would want to test
chk->p_priority > curpriority
rather than
chk->p_priority < curpriority
In other words, if the current process priority has become less
favorable, shouldn't you do a need_resched so that if there is a
process on the run queue that has a more favorable priority than
the new priority, it will be selected to run?
The code seems conceptually ok if chk is NOT the current process.
2) Rather than comparing priorities, shouldn't you check to
see if the change in priority would put the process on a new
run queue? For example:
#define PPQ (128 / NQS) /* priorities per queue */
(chk->p_priority / PPQ) < (curpriority / PPQ)
The current test could provoke a need_resched even if there
would be no change in runqueue?
3) Is this code correct if chk is on a sleep queue?
Shouldn't there be a check to see if chk is runnable before
calling need_resched?
4) I can't find anyplace in the kernel code where the p_priority
structure member reflects the real time priority, if the process
is a real time or idle time process. ie. I can't find where
p_priority is ever affected by p_rtprio.prio . Have I missed
something?
If what I have stated is true, then it seems to me the comparison
of chk->p_priority to curpriority is only valid if both chk and
the current process have p_rtprio.type equal to RTP_PRIO_NORMAL.
If the RTP_PRIO_BASE of the two processes is equal, and if it
is not RTP_PRIO_NORMAL, I would think you would want to compare
the p_rtprio.prio values?
5) The test uses both "curpriority" and "curproc" in its test.
curpriority and curproc are sometimes set at different
points in the kernel, which raises the question of whether
curpriority might not reflect a priority that corresponds to
curproc. Possibly, as a purely practical matter, there will always
be a correspondence. In tracing through the code I haven't (yet)
been able to pinpoint a case where this would not be so.
However, wouldn't it be safer to test chk->p_priority
against curproc->p_priority rather than curpriority, if chk
and curproc are not the same?
6) I haven't really studied the SMP code. What do curproc
and curpriority mean if there are multiple CPUs? Would
the comparisons still be valid if chk and curproc were on
different CPUs? Or, if chk is not currently running, should
the comparisons be against all the currently running processes?
--
Richard Seamman, Jr. email: dick@tar.com
5182 N. Maple Lane phone: 414-367-5450
Chenequa WI 53058 fax: 414-367-5852
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981229084305.A502>