Date: Tue, 25 Nov 2008 09:50:04 GMT From: Garrett Cooper <yanefbsd@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/129164: Wrong priority value for normal processes Message-ID: <200811250950.mAP9o4Xd093354@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/129164; it has been noted by GNATS.
From: Garrett Cooper <yanefbsd@gmail.com>
To: Unga <unga888@yahoo.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/129164: Wrong priority value for normal processes
Date: Tue, 25 Nov 2008 01:26:07 -0800
On Nov 25, 2008, at 12:31 AM, Unga wrote:
>
>> Number: 129164
>> Category: kern
>> Synopsis: Wrong priority value for normal processes
>> Confidential: no
>> Severity: serious
>> Priority: high
>> Responsible: freebsd-bugs
>> State: open
>> Quarter:
>> Keywords:
>> Date-Required:
>> Class: sw-bug
>> Submitter-Id: current-users
>> Arrival-Date: Tue Nov 25 08:40:05 UTC 2008
>> Closed-Date:
>> Last-Modified:
>> Originator: Unga
>> Release: FreeBSD 7.0-STABLE
>> Organization:
>> Environment:
> FreeBSD grey.lan 7.0-STABLE FreeBSD 7.0-STABLE Sun May 25 2008 i386
>> Description:
> 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.
>
> I have marked this issue as "serious". It is serious because normal
> priority processes crawl on my machine.
>
> 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".
>
>
>> How-To-Repeat:
> Compile and run the following program:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <sys/rtprio.h>
>
> main(int argc, char * argv[])
> {
> struct rtprio rtp;
>
> if (rtprio(RTP_LOOKUP, 0, &rtp))
> {
> printf("Cannot get priority!\n");
> exit(-1);
> }
>
> printf("Priority %d\n", rtp.prio);
> }
>
> The priority class can be obtained by running rtprio.
>> Fix:
> I find it bit difficult to understand why the priority value get
> changed as I explained under Full Description. If somebody could
> help me to find where the problem is, I could possibly be able to
> develop a patch.
>
>> Release-Note:
>> Audit-Trail:
>> Unformatted:
rtp.prio is an unsigned short, and there is some rollover because the
number set for the priority is then subtracted by 128 (see the
following grepped snippets). This appears to be a cosmetic issue which
should be fixed by shifting the starting offset for the priorities.
Unless it's really a dealbreaker (because it shouldn't be considering
that all processes are in fact fudged by this value range, but it does
touch the ULE / scheduler code a bit from the looks of it), I would
mark this bug Sev 2, Priority High.
[gcooper@optimus ~]$ grep -rn PRI_MIN_REALTIME /usr/src/sys/
/usr/src/sys/kern/kern_resource.c:479: newpri = PRI_MIN_REALTIME +
rtp->prio;
/usr/src/sys/kern/kern_resource.c:511: rtp->prio = td-
>td_base_user_pri - PRI_MIN_REALTIME;
/usr/src/sys/kern/kern_umtx.c:1934: if (UPRI(td) < PRI_MIN_REALTIME +
ceiling) {
/usr/src/sys/kern/kern_umtx.c:1939: if (su && PRI_MIN_REALTIME +
ceiling < uq->uq_inherited_pri) {
/usr/src/sys/kern/kern_umtx.c:1940: uq->uq_inherited_pri =
PRI_MIN_REALTIME + ceiling;
/usr/src/sys/kern/kern_umtx.c:2069: new_inherited_pri =
PRI_MIN_REALTIME + rceiling;
/usr/src/sys/kern/sched_ule.c:1406: pri = PRI_MIN_REALTIME;
/usr/src/sys/kern/sched_ule.c:1407: pri += ((PRI_MAX_REALTIME -
PRI_MIN_REALTIME) / sched_interact)
/usr/src/sys/kern/sched_ule.c:1409: KASSERT(pri >= PRI_MIN_REALTIME
&& pri <= PRI_MAX_REALTIME,
/usr/src/sys/sys/priority.h:98:#define PRI_MAX_KERN (PRI_MIN_REALTIME
- 1)
/usr/src/sys/sys/priority.h:112:#define PRI_MIN_REALTIME (128)
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811250950.mAP9o4Xd093354>