On Tue, 2018-01-09 at 22:26 +0100, Jesper Dangaard Brouer wrote:
I've previously experienced that you can be affected by the scheduler
granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y):
$ grep -H . /proc/sys/kernel/sched_*_granularity_ns
/proc/sys/kernel/sched_min_granularity_ns:2250000
/proc/sys/kernel/sched_wakeup_granularity_ns:3000000
The above numbers were confirmed on the RPi2 (see[2]). With commit
4cd13c21b207 ("softirq: Let ksoftirqd do its job"), I expect/assume that
softirq processing latency is bounded by the sched_wakeup_granularity_ns,
which with 3 ms is not good enough for their use-case.
Note of caution wrt twiddling sched_wakeup_granularity_ns: it must
remain < sched_latency_ns/2 else you effectively disable wakeup
preemption completely, turning CFS into a tick granularity scheduler.
-Mike