From owner-freebsd-hackers Fri Oct 19 0: 8:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.asplinux.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id A925037B403; Fri, 19 Oct 2001 00:08:11 -0700 (PDT) Received: from home.com (sashkin.asplinux.ru [192.168.1.108]) by relay.asplinux.ru (8.11.6/8.11.6) with ESMTP id f9J789818806; Fri, 19 Oct 2001 11:08:10 +0400 Message-ID: <3BCFD1CB.10609@home.com> Date: Fri, 19 Oct 2001 11:10:03 +0400 From: Alex Levine Reply-To: sashkin@home.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010829 X-Accept-Language: en-us MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@FreeBSD.org Subject: Re: Possible bug in scheduler. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 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