diff options
author | Eric Dumazet <edumazet@google.com> | 2016-05-23 14:24:56 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2016-05-24 14:49:14 -0700 |
commit | a9efad8b24bd22616f6c749a6c029957dc76542b (patch) | |
tree | 20ab7182ee4b4fef2afebd14c960c0a3d9920c56 /net/rxrpc/ar-input.c | |
parent | 3275c0c6c522ab04afa14f80efdac6213c3883d6 (diff) | |
download | op-kernel-dev-a9efad8b24bd22616f6c749a6c029957dc76542b.zip op-kernel-dev-a9efad8b24bd22616f6c749a6c029957dc76542b.tar.gz |
net_sched: avoid too many hrtimer_start() calls
I found a serious performance bug in packet schedulers using hrtimers.
sch_htb and sch_fq are definitely impacted by this problem.
We constantly rearm high resolution timers if some packets are throttled
in one (or more) class, and other packets are flying through qdisc on
another (non throttled) class.
hrtimer_start() does not have the mod_timer() trick of doing nothing if
expires value does not change :
if (timer_pending(timer) &&
timer->expires == expires)
return 1;
This issue is particularly visible when multiple cpus can queue/dequeue
packets on the same qdisc, as hrtimer code has to lock a remote base.
I used following fix :
1) Change htb to use qdisc_watchdog_schedule_ns() instead of open-coding
it.
2) Cache watchdog prior expiration. hrtimer might provide this, but I
prefer to not rely on some hrtimer internal.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/rxrpc/ar-input.c')
0 files changed, 0 insertions, 0 deletions