[Bug 1162728] [NEW] confusion about priorities

robert.berger launchpad at reliableembeddedsystems.com
Mon Apr 1 09:40:13 UTC 2013


Public bug reported:

man page:
pri        PRI     priority of the process. Higher number means lower priority.

In my tests I manipulate priorites and run afterwards:

ps -C -e -o class,rtprio,pri,nice,cmd
ps -e -o class,rtprio,pri,nice,cmd | grep "fork_1.out"

-----
1) default prio

./fork_1.out

CLS RTPRIO PRI  NI CMD
TS       -         19    0 ./fork_1.out

-----
2) nice lower prio

nice -n 19 ./fork_1.out

CLS RTPRIO PRI  NI CMD
TS       -         0      19 ./fork_1.out

The above has a higher priority 19>0, man pages for ps say that higher number means lower priority, so this is inconsistent.
-----

3) nice higher prio
sudo nice -n -20 ./fork_1.out

CLS RTPRIO PRI  NI CMD
TS       -          39  -20 ./fork_1.out

Here the PRI is 39>19>0, although this shoul now be be highest possible
priority in the TS class - inconsistent

-----

chrt -m
SCHED_OTHER min/max priority    : 0/0
SCHED_FIFO min/max priority     : 1/99
SCHED_RR min/max priority       : 1/99
SCHED_BATCH min/max priority    : 0/0
SCHED_IDLE min/max priority     : 0/0

-----

4)  highest rt prio

sudo chrt -r 99 ./fork_1.out

CLS RTPRIO PRI  NI CMD
RR  99          139   -  ./fork_1.out

139>39>19>0 this should be the highest available RT priority -
inconsistent

-----

5) lowest rt prio

sudo chrt -f 1 ./fork_1.out

CLS RTPRIO PRI  NI CMD
FF       1         41    -   ./fork_1.out
FF       1         41    -   ./fork_1.out

this should be the lowest available RT priority - inconsistent

------

Besides:
The RT-priorites go from 1 (lowest) to 99 (highest), which seems OK, but the same range maps to 41 to 139, which IMHO maps to a kernel static priority for 1 to 99.

Since the first nice priority (-n 20 maps to a Prio value of 39) the
questions is what happened to 40?

What we see is:
Priority values from 0 to 139 with a gap at 40 seem to map to static kernel priorities of 139 to 1 (which would explain the gap).

Anyhow is this really how it's supposed to be?

What should prio is ps show?

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: procps 1:3.2.8-11ubuntu6
ProcVersionSignature: Ubuntu 3.2.0-35.55-generic-pae 3.2.34
Uname: Linux 3.2.0-35-generic-pae i686
ApportVersion: 2.0.1-0ubuntu17.1
Architecture: i386
Date: Mon Apr  1 12:14:19 2013
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
MarkForUpload: True
SourcePackage: procps
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: procps (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: apport-bug i386 precise running-unity

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1162728

Title:
  confusion about priorities

Status in “procps” package in Ubuntu:
  New

Bug description:
  man page:
  pri        PRI     priority of the process. Higher number means lower priority.

  In my tests I manipulate priorites and run afterwards:

  ps -C -e -o class,rtprio,pri,nice,cmd
  ps -e -o class,rtprio,pri,nice,cmd | grep "fork_1.out"

  -----
  1) default prio

  ./fork_1.out

  CLS RTPRIO PRI  NI CMD
  TS       -         19    0 ./fork_1.out

  -----
  2) nice lower prio

  nice -n 19 ./fork_1.out

  CLS RTPRIO PRI  NI CMD
  TS       -         0      19 ./fork_1.out

  The above has a higher priority 19>0, man pages for ps say that higher number means lower priority, so this is inconsistent.
  -----

  3) nice higher prio
  sudo nice -n -20 ./fork_1.out

  CLS RTPRIO PRI  NI CMD
  TS       -          39  -20 ./fork_1.out

  Here the PRI is 39>19>0, although this shoul now be be highest
  possible priority in the TS class - inconsistent

  -----

  chrt -m
  SCHED_OTHER min/max priority    : 0/0
  SCHED_FIFO min/max priority     : 1/99
  SCHED_RR min/max priority       : 1/99
  SCHED_BATCH min/max priority    : 0/0
  SCHED_IDLE min/max priority     : 0/0

  -----

  4)  highest rt prio

  sudo chrt -r 99 ./fork_1.out

  CLS RTPRIO PRI  NI CMD
  RR  99          139   -  ./fork_1.out

  139>39>19>0 this should be the highest available RT priority -
  inconsistent

  -----

  5) lowest rt prio

  sudo chrt -f 1 ./fork_1.out

  CLS RTPRIO PRI  NI CMD
  FF       1         41    -   ./fork_1.out
  FF       1         41    -   ./fork_1.out

  this should be the lowest available RT priority - inconsistent

  ------

  Besides:
  The RT-priorites go from 1 (lowest) to 99 (highest), which seems OK, but the same range maps to 41 to 139, which IMHO maps to a kernel static priority for 1 to 99.

  Since the first nice priority (-n 20 maps to a Prio value of 39) the
  questions is what happened to 40?

  What we see is:
  Priority values from 0 to 139 with a gap at 40 seem to map to static kernel priorities of 139 to 1 (which would explain the gap).

  Anyhow is this really how it's supposed to be?

  What should prio is ps show?

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: procps 1:3.2.8-11ubuntu6
  ProcVersionSignature: Ubuntu 3.2.0-35.55-generic-pae 3.2.34
  Uname: Linux 3.2.0-35-generic-pae i686
  ApportVersion: 2.0.1-0ubuntu17.1
  Architecture: i386
  Date: Mon Apr  1 12:14:19 2013
  InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
  MarkForUpload: True
  SourcePackage: procps
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1162728/+subscriptions




More information about the foundations-bugs mailing list