On 2018-08-26 20:39:22 [-0700], Ramesh Thomas wrote: > Case #2 with CONFIG_PREEMPT_RT_FULL=y (First run after boot) > S [cpuhp/3] > S [migration/3] > S [posixcputmr/3] > S [rcuc/3] > S [ktimersoftd/3] > S [ksoftirqd/3] > I [kworker/3:0-mm_] > I [kworker/3:0H] > R [irq/125-nvme0q4] > R [kworker/3:1-mm_] > R ./jitter irq/125 shouldn't be there, right? > Case #3 with CONFIG_PREEMPT_RT_FULL=y (Second run after boot) > S [cpuhp/3] > S [migration/3] > S [posixcputmr/3] > S [rcuc/3] > R [ktimersoftd/3] > S [ksoftirqd/3] > I [kworker/3:0-mm_] > I [kworker/3:0H] > S [irq/125-nvme0q4] > R [kworker/3:1-mm_] > R ./jitter > > In Case #3, /proc/interupts show timer interrupts occuring on CPU 3 while it > is stopped in the other cases. ktimersoftd is in runnable state in Case #3 can you trace down who or what is arming the timer on CPU3? > Is this a known issue and is it being looked at by anyone? now that I know of. Do you happen to know if this is a regression compared to v4.14-RT? > 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). > Thanks, > Ramesh Sebastian
