Date: Fri, 19 Oct 2001 11:10:03 +0400 From: Alex Levine <sashkin@home.com> To: John Baldwin <jhb@FreeBSD.org>, freebsd-hackers@FreeBSD.org Subject: Re: Possible bug in scheduler. Message-ID: <3BCFD1CB.10609@home.com> References: <XFMail.011018080559.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: >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. > I took another look in CURRENT. The same call to maybe_resched from reset_priority is as useless as in STABLE. Only there the recalculation relies on pri_level, which replaced p_priority as I understand but the thing which is being changed is usr_pri. So it's the same. Regards, Alex Levine 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?3BCFD1CB.10609>