Date: Tue, 29 Dec 1998 12:00:09 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: dick@tar.com (Richard Seaman, Jr.) Cc: hackers@FreeBSD.ORG Subject: Re: maybe_resched() -- Help me understand it? Message-ID: <199812291700.MAA05701@hda.hda.com> In-Reply-To: <19981229084305.A502@tar.com> from "Richard Seaman, Jr." at "Dec 29, 98 08:43:05 am"
next in thread | previous in thread | raw e-mail | index | archive | help
I'll answer a few questions and then let someone either correct me
or let you check up on me and refine your questions further.
(...)
> /* 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.
For a normal time sharing process,
the current process will lose the CPU if it decays to the point that it
drops into a lower priority run queue. That will be handled by
removing and reinserting so that it winds up in the right queue, and
whatever was behind it in the queue will start up. The four levels
of priority within a given run queue are treated as identical for
scheduling purposes and the system will round-robin across those.
Since without outside events that will cause recalculation of priorities
you normally only decay (level increase), "chk->p_priority < curpriority" won't
return true for curproc. I guess that raising your priority brute
force does indeed result in an extra reschedule but that shouldn't happen
too much. This should answer your next question
about why not just check to see if we drop into a new run queue.
(...)
> 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?
The code assumes it is always passed a runnable process.
> 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?
It is done in the machine specific code - check in i386/i386. To
predict your next question, there are only 32 levels of
real time priority corressponding to the 32 run queues in the
time sharing world.
Peter
--
Peter Dufault (dufault@hda.com) Realtime development, Machine control,
HD Associates, Inc. Safety critical systems, Agency approval
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?199812291700.MAA05701>