On 2017-02-13 18:48:33 [+0000], Patel, Vedang wrote: > I am getting very similar results even if I change the priority of > ktimersoftd to 99. Are there any recent rt patches which might have > changed the behaviour of POSIX timers? I had this running |~# cyclictest -t1 -p 80 -i 500 -l 100000 |# /dev/cpu_dma_latency set to 0us |policy: fifo: loadavg: 627.48 661.98 543.65 406/2254 18149 | |T: 0 (16148) P:80 I:500 C: 100000 Min: 5 Act: 11 Avg: 11 Max: 23 on a AMD-A10 box and the latest v4.9-RT. This does not look that bad. >From tracing it doesn't look too good either. The -m option should be your friend. Since the cyclictest isn't pinned to a CPU and I have four of them, the scheduler decides to migrate cyclictest on each wake up. yay. cyclictest itself gets woken up via a signal from the ktimersoftirq. > Also, are POSIX timers really suited for "real-time" applications?I > believe a similar question was raised by Ran Shalit a few days back: > http://www.spinics.net/lists/linux-rt-users/msg16249.html So it seems to work with no regression as far as I can tell. Due to the timersoftirq context switch I would suggest to use clock_nanosleep if possible. > Thanks, > Vedang Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
