On 2018-08-31 01:18:20 [-0700], Ramesh Thomas wrote:

Yes. Also posixcputmr and ktimersoftd are not seen if PREEMPT_RT_FULL is not 
enabled. They don't seem to be running when the timer interrupts occur. But 
they being there by itself indicates something different is happening.

both threads are created on RT and should be idle unless used.

I see the issue in 4.14.63 RT as well. There are slight differences in 
behavior due to changes that went in 4.17, but the main issue is seen there 
also.

okay, so it is not a regression. Thanks for confirming.

quoted

quoted

If it is an issue, I would be glad to help in any way to get these 2 very
important features compatible with each other.

So if the ktimersoftd runs and you see the interrupt counter
incrementing for CPU3 then it would be interesting to figure out why
there is an armed timer on the second invocation (and none on the first
one).

In 4.18.5 RT, the issue does not always happen in the second invocation.  
Sometimes it works as expected, but the issue will show up after a few 
tries.

Looks like there are 2 issues when PREEMPT_RT_FULL is enabled
1. Some additional processes are pinned to isolated cores.

as explained, above that is expected.

2. Timer is armed even though only a single high priority task is running.

something must have armed that timer. The clock_nanosleep() API won't
use those new threads but for instance timer_create() / timer_settime()
will.

quoted

quoted

Thanks,
Ramesh

Sebastian