[rt2x00-users] [PATCH 3.3] rt2x00: fix random stalls
m.hundeboll at gmail.com
Wed Mar 7 04:43:56 EST 2012
On 03/05/2012 05:48 PM, Stanislaw Gruszka wrote:
> Is possible that we stop queue and then do not wake up it again,
> especially when packets are transmitted fast. That can be easily
> reproduced with modified tx queue entry_num to some small value e.g. 16.
> If mac80211 already hold local->queue_stop_reason_lock, then we can wait
> on that lock in both rt2x00queue_pause_queue() and
> rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock
> is possible that __ieee80211_wake_queue() will be performed before
> __ieee80211_stop_queue(), hence we stop queue and newer wake up it
> To prevent stalls serialize pause/unpause by queue->tx_lock.
I've been having CPU load issues with rt2800usb/Ralink RT2870, when doing simultaneous TX/RX between to nodes in an adhoc network. While transfering UDP packets in one direction with iperf, I get ~23Mbit/s and kworker is utilizing <10% of the CPU (OMAP4 1GHz dualcore or/and Pentium M 1.70GHz) on both ends. When doing bidirectional tests with iperf, one kworker thread jumps too 100% and throughput drops.
By using two iperf clients to do bidirectional TCP transfers, I got ~6Mbit/s in both directions, so I suspected some queueing issues and thus applied this patch, but no change. I've tried to do some tracing, but this is quite new to me, so please instruct me, if you need more info.
iperf unidirectional cmd and output:
# iperf -c10.10.10.56 -ub50M
0.0-10.0 sec 27.5 MBytes 22.9 Mbits/sec 1.639 ms 0/19602 (0%)
iperf bidirectional cmd and output:
# iperf -c10.10.10.56 -udb8M
Sent 2501 datagrams
[ 3] 0.0-11.0 sec 1.26 MBytes 963 Kbits/sec 22.437 ms 943/ 1840 (51%)
[ 4] 0.0-10.9 sec 2.11 MBytes 1.62 Mbits/sec 309.803 ms 993/ 2500 (40%)
out.txt has a trace from 10.10.10.55 while running iperf as in  and the following commands:
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the users