From owner-freebsd-bugs@FreeBSD.ORG Thu Nov 27 10:26:36 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 202CB1065674 for ; Thu, 27 Nov 2008 10:26:36 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id F3A508FC0A for ; Thu, 27 Nov 2008 10:26:35 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id b25so856419rvf.43 for ; Thu, 27 Nov 2008 02:26:35 -0800 (PST) Received: by 10.141.115.20 with SMTP id s20mr3346760rvm.70.1227780341015; Thu, 27 Nov 2008 02:05:41 -0800 (PST) Received: from ?10.0.1.199? (cpe-66-91-191-118.hawaii.res.rr.com [66.91.191.118]) by mx.google.com with ESMTPS id g31sm2492949rvb.7.2008.11.27.02.05.38 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Nov 2008 02:05:40 -0800 (PST) Date: Thu, 27 Nov 2008 00:03:18 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Unga In-Reply-To: <484904.78100.qm@web57001.mail.re3.yahoo.com> Message-ID: <20081127000235.D971@desktop> References: <484904.78100.qm@web57001.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: yanefbsd@gmail.com, freebsd-bugs@freebsd.org, jeff@freebsd.org, brde@optusnet.com.au, jhb@freebsd.org Subject: Re: kern/129164: Wrong priority value for normal processes X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2008 10:26:36 -0000 On Thu, 27 Nov 2008, Unga wrote: > --- 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. The base_pri vs td_priority is really jhb's domain. I added him to the cc. Thanks, Jeff > > 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 > > > >