From owner-freebsd-hackers Thu Oct 18 5:34:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from r220-1.rz.RWTH-Aachen.DE (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by hub.freebsd.org (Postfix) with ESMTP id 5303537B407 for ; Thu, 18 Oct 2001 05:34:22 -0700 (PDT) Received: from r220-1.rz.RWTH-Aachen.DE (relay2.RWTH-Aachen.DE [134.130.3.1]) by r220-1.rz.RWTH-Aachen.DE (8.10.1/8.11.3-2) with ESMTP id f9ICYJj22088; Thu, 18 Oct 2001 14:34:19 +0200 (MEST) Received: from kawoserv.kawo2.rwth-aachen.de (root@kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by r220-1.rz.RWTH-Aachen.DE (8.10.1/8.11.3/6) with ESMTP id f9ICYJo22084; Thu, 18 Oct 2001 14:34:19 +0200 (MEST) Received: from zerogravity.kawo2.rwth-aachen.de (zerogravity.kawo2.rwth-aachen.de [134.130.181.28]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id OAA28218; Thu, 18 Oct 2001 14:34:15 +0200 Received: by zerogravity.kawo2.rwth-aachen.de (Postfix, from userid 1001) id 52AB214A21; Thu, 18 Oct 2001 14:34:15 +0200 (CEST) Date: Thu, 18 Oct 2001 14:34:14 +0200 From: Alexander Langer To: sashkin@home.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible bug in scheduler. Message-ID: <20011018143414.C2064@zerogravity.kawo2.rwth-aachen.de> References: <3BCE92F0.8090809@asplinux.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BCE92F0.8090809@asplinux.ru>; from sashkin@asplinux.ru on Thu, Oct 18, 2001 at 12:29:36PM +0400 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Alex Levine (sashkin@asplinux.ru): > resetpriority() calls maybe_resched() at the end after updating p_usrpri > based on changed p_estcpu. > maybe_resched() uses curpriority_cmp to compare priorities of current > and given process and this function ( curpriority_cmp ) uses p_priority > which is unchanged yet - the new p_usrpri is not reflected to p_priority > yet. In -CURRENT, it's more obvious: maybe_resched() only rescheds, if the resetted process' priority level changes. Since resetpriority() doesn't modify the priority level but only the user priority, the call to maybe_resched() has no effect at all -- only some overhead for the comparisons (curproc will have had the higher or same priority level as the resetted process anyways, otherwise it hadn't been curproc :) So, either - p's priority level in resetpriority has to be re-calculted as well, or - the call to maybe_resched() can be removed w/o loss of functionality. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message