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
