4

Can someone explain how "real" process priority (i.e. pri_baz field of ps) is calculated?

My guess is:

pri_baz = 99 - static_priority  # if static_priority > 0 (real-time process)
pri_baz = 100 + min(20 + nice + dynamic_adjustment, 39)  # if static_priority = 0 (time-shared process)

This is supported by the following test:

# chrt -r 1 sleep 1 \
> & chrt -r 99 sleep 1 \
> & nice --20 sleep 1 \
> & nice -19 sleep 1 \
> & ps -C sleep -O pri_baz
[1] 25408
[2] 25409
[3] 25410
[4] 25411
   PID BAZ S TTY          TIME COMMAND
 25408  98 S pts/3    00:00:00 sleep 1
 25409   0 S pts/3    00:00:00 sleep 1
 25410 100 S pts/3    00:00:00 sleep 1
 25411 139 S pts/3    00:00:00 sleep 1

However I'm puzzled because:

  1. pri_baz = 99 appears to be unused.

  2. I knew Linux handled (by default) 140 priority queues, and this scheme gives only 139 values of priority.

2 Answers 2

6

In ps’s output, pri_baz is calculated as pp->priority + 100, and pp->priority is the prio value from the kernel. This is described as

Priority of a process goes from 0..MAX_PRIO-1, valid RT priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH tasks are in the range MAX_RT_PRIO..MAX_PRIO-1. Priority values are inverted: lower p->prio value means higher priority.

The MAX_USER_RT_PRIO value allows the actual maximum RT priority to be separate from the value exported to user-space. This allows kernel threads to set their priority to a value higher than any user task. Note: MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.

So the range in the kernel does cover 140 values, from 0 to MAX_PRIO–1 (139).

However, the minimum FIFO and RT priority is 1, and this explains the missing value: the input values (at least, that can be set from userspace, using sched_setscheduler) go from 1 to 99, and the kernel converts those to prio values using the formula MAX_RT_PRIO – 1 – priority, giving values from 0 to 98.

1

I am new to this (not an expert). I see 0 and 139, this suggests a range of at least 140. I see you setting real time priority to 1 and 99, but see it reported as 0 and 98. I see the nice of a range of 40, both for what you asked for, and what is reported. So may be some -1 involved. But I see nothing special about 99.

The highest it can set with chrt -r is 99. This reports as 98.

It looks like someone made an out-by-one-error in the implementation some-where.

1
  • Just counting from 0...
    – vonbrand
    Commented Feb 18, 2020 at 3:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .