Pleaee isolate the specific release where latency regression occurred if the community has not already done so. Possibly backing out changes specific to timers and posix threads for that release to see what impacted latency. This is crucial for NXP and others as they migrate to later releases of the kernel. Also please share your latency numbers while testing for regression for each release if possible. Using: taskset -c 2 cyclictest -m -n -P -p 99 -t 1 -i 10000-136000000 taskset -c 3 cyclictest -m -n -P -p 99 -t 1 -i 10000000 -l 0 On an ARM-8 Cortex-A53 NXP LS1043ARDB 4x core the latency was approx 3 us min/avg and max 7 with no latency spikes on 4.1.30-rt34+g667e6ba SMP PREEMPT RT NXP SDK 2.0-1609. Used sar, iperf, and stress for load. Tracy Smith Software Engineer DSC > On Mar 1, 2017, at 9:22 AM, "bigeasy@xxxxxxxxxxxxx" <bigeasy@xxxxxxxxxxxxx> wrote: > >> On 2017-02-22 01:43:09 [+0000], Patel, Vedang wrote: >> Also, I checked the number of cpu migrations and context switches using >> perf stat. Following are the results for both the cases: >> >> cyclictest not pinned to CPU: the number of CPU migrations and context >> switches are equal to the number of loops I am running for cyclictest. >> Here, there are a lot of context switches with the ktimersoftd process. >> >> cyclictest pinned to a CPU: there are very few CPU migrations. But, the >> number of context switches are approximately 3 times the number of >> loops. Most of the context switches are with the swapper (idle) >> process. >> >> In both the cases, the number of page faults are pretty low (~65). >> >> I also tried similar experiments with mainline kernel (v4.4.47). The >> number of CPU migrations were pretty low (single digits) for both the >> cases described above. Also, the number of context switches were equal >> to the number of loops provided as an argument to cyclictest. > > The hardware interrupt wakes the "timer-softirq" thread. This RT-thread > in turn will wake up your application / cyclictest which uses the > posix-timers. So the priority of this thread is also important. After > the wakeup it is possible that the newer kernel tries migrate the RT > task if possible in order to keep it running as soon as possible. If it > does not migrate it, then either the cyclictest task has to wait or the > "timer-softirq" thread. > >> Thanks, >> Vedang Patel >> Software Engineer >> Intel Corporation > > 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 -- 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
