Date: Thu, 18 Oct 2001 08:05:59 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Alexander Langer <alex@big.endian.de> Cc: freebsd-hackers@FreeBSD.ORG, sashkin@home.com Subject: Re: Possible bug in scheduler. Message-ID: <XFMail.011018080559.jhb@FreeBSD.org> In-Reply-To: <20011018143414.C2064@zerogravity.kawo2.rwth-aachen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18-Oct-01 Alexander Langer wrote: > 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. or c) in the preemptive kernel maybe_resched() doesn't exist as it's functionality is more properly handled in other places. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.011018080559.jhb>