From owner-freebsd-hackers Tue Dec 29 09:03:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA19294 for freebsd-hackers-outgoing; Tue, 29 Dec 1998 09:03:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19286 for ; Tue, 29 Dec 1998 09:03:40 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id MAA05701; Tue, 29 Dec 1998 12:00:09 -0500 (EST) From: Peter Dufault Message-Id: <199812291700.MAA05701@hda.hda.com> Subject: Re: maybe_resched() -- Help me understand it? In-Reply-To: <19981229084305.A502@tar.com> from "Richard Seaman, Jr." at "Dec 29, 98 08:43:05 am" To: dick@tar.com (Richard Seaman, Jr.) Date: Tue, 29 Dec 1998 12:00:09 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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