On Wed, Feb 15, 2017 at 05:54:47PM +0100, bigeasy@xxxxxxxxxxxxx wrote: > 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. Perhaps a separate off-shoot topic, but has there been significant changes in v4.9 upstream (or v4.9-rt) which impact how often migration is performed? We've seen what appears to be much more aggressive migration of SCHED_FAIR tasks, (aggressive in the sense that more threads are migrated more often), which appears to cause contention on rq-locks impacting latencies in the wake_up paths. We're still working to further characterize at this point....hopefully more information forthcoming. Julia -- 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
