From owner-freebsd-hackers Tue Dec 29 06:43:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA06617 for freebsd-hackers-outgoing; Tue, 29 Dec 1998 06:43:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA06612 for ; Tue, 29 Dec 1998 06:43:24 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.1/8.9.1) id IAA00566 for hackers@freebsd.org; Tue, 29 Dec 1998 08:43:05 -0600 (CST) (envelope-from dick) Date: Tue, 29 Dec 1998 08:43:05 -0600 From: "Richard Seaman, Jr." To: hackers@FreeBSD.ORG Subject: maybe_resched() -- Help me understand it? Message-ID: <19981229084305.A502@tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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