Re: RT linux and priorities

[Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>]

On 2/2/21 11:48 AM, Konrad, Martin wrote:
> Hi Michael,
>> It looks like the ISR threads default to SCHED_FIFO/50, which is also what
>> epicsThreadPriorityMedium currently maps to.  So eg. the 1 second scan task
>> has a higher priority (63) than the NIC ISR thread (50).  This seems like
>> a recipe for some unexpected priority inversions.
> 
> Looking at the output of your "ps" command the header of the first two
> columns say "RTPRIO" and "PRI" (in this order). It seems like you are
> comparing numbers in the "PRI" column. The man page of "ps" says:
> 
> pri         PRI       priority of the process.  Higher number means
>                       lower priority.

I'm not sure I believe this statement.  This sounds like 'nice', not
priority.  This would mean that my system is somehow giving firefox
precedence over IRQs.

>    10  50   -  RR 17801 /usr/lib/firefox-esr/firefox-esr ...
...
>    50  90   -  FF 26049 [irq/172-mei_me]
>    50  90   -  FF 31826 ../../bin/linux-x86_64/pscdemo st.cmd


> If I understand that correctly 63 would mean _lower_ priority than _50_.
> I'm not sure if the fact that SCHED_RR is active changes the meaning of
> these numbers.

I'm looking at the rtprio column.  While I didn't include it, I was also
looking at the output of epicsThreadShowAll().  The OSS priorities shown
there match the 'rtprio' column of 'ps'.  So I'm confident that this number
is what was passed to pthread_attr_setschedparam(), which in this case has
a 1-to-1 mapping from EPICS OSI priorities (again from epicsThreadShowAll).
(I ran this test as root to avoid permissions complications)

>> Now I'm also wondering how firefox is able to set SCHED_RR/10

firefox is asking the rtkit-daemon to do this.  Apparently the default
policy (a la policykit) is to allow processes associated with a session
to bypass RLIMIT_RTTIME.  With MaxRealtimePriority=20.  Who knew...

cf. /usr/share/polkit-1/actions/org.freedesktop.RealtimeKit1.policy