Date: Thu, 18 Oct 2001 14:34:14 +0200 From: Alexander Langer <alex@big.endian.de> To: sashkin@home.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible bug in scheduler. Message-ID: <20011018143414.C2064@zerogravity.kawo2.rwth-aachen.de> In-Reply-To: <3BCE92F0.8090809@asplinux.ru>; from sashkin@asplinux.ru on Thu, Oct 18, 2001 at 12:29:36PM %2B0400 References: <3BCE92F0.8090809@asplinux.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011018143414.C2064>