Bug 129164 - [kernel] Wrong priority value for normal processes
Summary: [kernel] Wrong priority value for normal processes
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 7.0-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-25 08:40 UTC by Unga
Modified: 2017-12-31 22:35 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Unga 2008-11-25 08:40:05 UTC
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".

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.
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.
Comment 1 Garrett Cooper 2008-11-25 09:26:07 UTC
	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
Comment 2 Unga 2008-11-25 10:41:26 UTC
Thanks for the reply.

I'll look more details into your above grep results.

I forgot to mention, this issue does not effect both realtime and idletime. It only effect normal priority class. That is, the priority set for the normal processes does not retain.

Best regards
Unga
Comment 3 Unga 2008-11-25 12:12:24 UTC
All above realtime priority calculations seems to be correct as per the /usr/src/sys/sys/priority.h.

Let me check the possibility whether there is any priority translation error in rtprio(2). Could I know where the rtprio(2) is implemented?

Regards
Unga
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:47 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped