| commit | 8236632fb3532188c75656421e29f5ab51b47db7 | |
| author | Jamal Hadi Salim <hadi@cyberus.ca> | |
| Wed, 26 Sep 2007 02:27:13 +0000 (25 19:27 -0700) | ||
| committer | David S. Miller <davem@sunset.davemloft.net> | |
| Wed, 10 Oct 2007 23:52:15 +0000 (10 16:52 -0700) | ||
| tree | e93f1c710c420fb643ddb424f0db974ac4e064f2 | treesnapshot (tar.gz zip) |
| parent | 854d8363f37491c955b0edc60d37b62f3d71bb67 | commitdiff |
[NET_SCHED]: explict hold dev tx lock
For N cpus, with full throttle traffic on all N CPUs, funneling traffic
to the same ethernet device, the devices queue lock is contended by all
N CPUs constantly. The TX lock is only contended by a max of 2 CPUS.
In the current mode of operation, after all the work of entering the
dequeue region, we may endup aborting the path if we are unable to get
the tx lock and go back to contend for the queue lock. As N goes up,
this gets worse.
The changes in this patch result in a small increase in performance
with a 4CPU (2xdual-core) with no irq binding. Both e1000 and tg3
showed similar behavior;
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
For N cpus, with full throttle traffic on all N CPUs, funneling traffic
to the same ethernet device, the devices queue lock is contended by all
N CPUs constantly. The TX lock is only contended by a max of 2 CPUS.
In the current mode of operation, after all the work of entering the
dequeue region, we may endup aborting the path if we are unable to get
the tx lock and go back to contend for the queue lock. As N goes up,
this gets worse.
The changes in this patch result in a small increase in performance
with a 4CPU (2xdual-core) with no irq binding. Both e1000 and tg3
showed similar behavior;
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
| net/sched/sch_generic.c | diffblobblamehistory |