Linux – Why highest priority threads are displayed with RT in top and htop

htoplinuxpriorityschedulingtop

In the top and htop tools, processes (or/and threads depending on display settings) having the highest realtime priority (99 from the userland API point of view) with either the scheduling policy SCHED_RR or SCHED_FIFO the priority is displayed as RT.

For all the other real time processes, the priority is displayed as a number p defined by:

p = -userprio -1

I am wondering why top and htop don't display -100 for higest priority real time processes ?

Best Answer

I am wondering why top and htop don't display -100 for highest priority real time processes ?

That's because SCHED_RR and SCHED_FIFO have fixed static priorities in the range 1-99: RedHat MRG docs on rt

For realtime priorities, the order is reversed: 99 is indeed the highest one, contrary to the usual "lower is higher".

Per your comment I misunderstood your question, sorry.

There is only one column in top, so differentiating the RT priorities from the other ones would not be possible. To get around this, "rt" is used to indicate that these processes use a realtime scheduler class.

You can see the difference using ps ax --format uname,pid,ppid,tty,cmd,cls,pri,rtprio, which will give you 2 columns, one for the prio and the other one for rtprio.

Sidenote: The aforementioned command will also show you the scheduler class the process uses (the cls field).

Related Solutions

Linux – What are the effects, if any, of scheduler priorities and policies for threads in an uncontended cpuset

The time slice used will matter for CPU intensive jobs that require cache persistence, unless you lock a particular core to each PID. You can increase the time slice with scheduler policy SCHED_BATCH and improve performance up to 300% in some cases, while reducing interactive responsiveness. The opposite effect of smaller time slices occurs with SCHED_RR (which will reduce throughput but increase real time responsiveness).

You can use schedtool to set the policy of specific PIDs for all PIDs in set B as a single command. It can also be used to lock specific PIDs to specific cores, which would be the optimal solution since then cache persistence no longer depends on the time slice, but this takes more effort since you have to run a separate schedtool command for each PID.

Kernel Process Scheduling – Real Time Processes Scheduling in Linux

Question 1

It is possible for an user to use real time priority for a process as well. This configuration could be set from /etc/security/limits.conf file. I see the below contents in that file.

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain>        <type>  <item>  <value>

If we check the item section, we see the below entry which enables to set a real time priority for the users.

#        - rtprio - max realtime priority

Question 2 and Question 3

To set scheduling policy to SCHED_FIFO, enter:

chrt -f -p [1..99] {pid}

To set scheduling policy to SCHED_RR, enter:

chrt -r -p [1..99] {pid}

So to answer question 3, we should verify the scheduling algorithms available and the priorities using the chrt -m command and then use any scheduling algorithm that suits our need. To set different priorities, we could use the commands as above.

Best Answer

Related Solutions

Linux – What are the effects, if any, of scheduler priorities and policies for threads in an uncontended cpuset

Kernel Process Scheduling – Real Time Processes Scheduling in Linux

Related Question