From owner-freebsd-bugs@FreeBSD.ORG Thu Nov 27 08:41:39 2008 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C45621065675 for ; Thu, 27 Nov 2008 08:41:39 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57001.mail.re3.yahoo.com (web57001.mail.re3.yahoo.com [66.196.97.105]) by mx1.freebsd.org (Postfix) with SMTP id 73D278FC20 for ; Thu, 27 Nov 2008 08:41:39 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 78131 invoked by uid 60001); 27 Nov 2008 08:41:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=eRV6PcD5inKZwOnZz/oGpuQVuRxS6CLsHiBos8j4uZ/O0EA8D48m10CvfWGaW4UER8EJoBP9jUyJwNVY5cA+Sy2JGWDxfrXBXQ7u/ALCRWrPVHkxm2Blp2dlyrW5RqXPxgCI3j+1tg5VJdv4RPTw8kKFkjgYMoIzg7aHtrSAHJQ=; X-YMail-OSG: S3PKzQEVM1lEOKxNTYurFj0O.aLvsIt5c_mcJSln_Jidktm_jMfOF7LaLmEcbf3i5P3sE.nHYSiIn01Re.DiX5G5L22a6wJfHQILUFTljW9Va.7yB.Q2GMZqXZ.3_bFJZDtZZs3ZVvaeLRuoQHoLe6sUCtKD5pBImB3aMLjP06tiPQuuQlMuCkV00Ytt Received: from [220.255.7.179] by web57001.mail.re3.yahoo.com via HTTP; Thu, 27 Nov 2008 00:41:38 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Thu, 27 Nov 2008 00:41:38 -0800 (PST) From: Unga To: freebsd-bugs@freebsd.org In-Reply-To: <200811250831.mAP8V6cP064024@www.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <484904.78100.qm@web57001.mail.re3.yahoo.com> Cc: yanefbsd@gmail.com, jeff@freebsd.org, brde@optusnet.com.au Subject: Re: kern/129164: Wrong priority value for normal processes X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2008 08:41:39 -0000 --- On Tue, 11/25/08, Unga wrote: > The priority value for root and other normal processes is > 65504 (rtp.prio) where zero (0) is expected. > > I checked the program flow from /usr/src/usr.bin/su/su.c to > /usr/src/lib/libutil/login_class.c and it looks > setusercontext() is setting the priority zero (0) right but > the moment it come out from the setusercontext() call in > su.c, the priority has already turn to 65504. > > Maximum priority value for normal priority processes can > take is 20, not 65504. Normal priority processes are > expected to run at priority zero (0) as it is specified in > /etc/login.conf under login class "default". > I have further checked the rtprio(2) system call for how it set and read priorities. Setting Priority: rtprio(RTP_SET, 0, &rtp) rtprio() => rtprio_thread() => rtp_to_pri() rtp_to_pri() calculates newpri as: newpri = PRI_MIN_TIMESHARE + rtp->prio; PRI_MIN_TIMESHARE is for normal priority, its PRI_MIN_REALTIME for realtime priority etc. Now rtp_to_pri() calls sched_class() to set the priority class. It sets td->td_pri_class to the priority class given. Then rtp_to_pri() calls sched_user_prio() to set the priority. It sets following fields to the priority calculated (newpri): td->td_base_user_pri td->td_user_pri Then rtp_to_pri() calls sched_prio(). It sets following field to the priority calculated (newpri): td->td_base_pri The sched_prio() calls sched_thread_priority() which sets td->td_priority to the priority calculated (newpri). Of course not all td->td_* fields are set in one go. Some are set conditionally. But the td->td_base_user_pri is always set. Reading Priority: rtprio(RTP_LOOKUP, 0, &rtp) rtprio() => rtprio_thread() => pri_to_rtp() At pri_to_rtp(), rtp->type and rtp->prio are set as follows: rtp->type = td->td_pri_class; rtp->prio = td->td_base_user_pri - PRI_MIN_TIMESHARE; That is, rtprio(2) system call sets the td->td_base_user_pri when request to set priority, and when request to read the priority, it reads the td->td_base_user_pri. In another word, for rtprio(2) to function properly the td->td_base_user_pri should not be changed. As the rtp->prio is unsigned short, for rtp->prio to become a huge number (65504), td->td_base_user_pri should be less than PRI_MIN_TIMESHARE. This shows the actual problem is in the scheduler. In this case, sched_ule. I presume the sched_ule should not touch the td->td_base_user_pri. Instead, probably, it should use td->td_priority for its internal purposes. Appreciate if Jeffrey Roberson could shed more light on this issue. Since I'm not conversant with the sched_ule, I may not be able to develop a fix for sched_ule. Appreciate either Jeffrey or somebody else could look into a fix for sched_ule. I can certainly help in apply a patch and test. Best regards Unga