On 04/28/2020 12:37 PM, Toke Høiland-Jørgensen wrote:
greearb@xxxxxxxxxxxxxxx writes:From: Ben Greear <greearb@xxxxxxxxxxxxxxx> While running tcp upload + download tests with ~200 concurrent TCP streams, 1-2 processes, and 30 station vdevs, I noticed that the __ieee80211_stop_queue was taking around 20% of the CPU according to perf-top, which other locking taking an additional ~15%. I believe the issue is that the ath10k driver would unlock the txqueue when a single frame could be transmitted, instead of waiting for a low water mark. So, this patch adds a low-water mark that is 1/4 of the total tx buffers allowed. This appears to resolve the performance problem that I saw. Tested with recent wave-1 ath10k-ct firmware. Signed-off-by: Ben Greear <greearb@xxxxxxxxxxxxxxx> --- drivers/net/wireless/ath/ath10k/htt.h | 1 + drivers/net/wireless/ath/ath10k/htt_tx.c | 8 ++++++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h index 31c4ddbf45cb..b5634781c0dc 100644 --- a/drivers/net/wireless/ath/ath10k/htt.h +++ b/drivers/net/wireless/ath/ath10k/htt.h @@ -1941,6 +1941,7 @@ struct ath10k_htt { u8 target_version_major; u8 target_version_minor; + bool needs_unlock; struct completion target_version_received; u8 max_num_amsdu; u8 max_num_ampdu; diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c index 9b3c3b080e92..44795d9a7c0c 100644 --- a/drivers/net/wireless/ath/ath10k/htt_tx.c +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c @@ -145,8 +145,10 @@ void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt) lockdep_assert_held(&htt->tx_lock); htt->num_pending_tx--; - if (htt->num_pending_tx == htt->max_num_pending_tx - 1) + if ((htt->num_pending_tx <= (htt->max_num_pending_tx / 4)) && htt->needs_unlock) {Why /4? Seems a bit arbitrary?
Yes, arbitrary for sure. I figure restart filling the queue when 1/4 full so that it is unlikely to run dry. Possibly it should restart sooner to keep it more full on average? Before my patch, the behaviour would be to try to keep it as full as possible, as in restart the queues as soon as a single slot opens up in the tx queue.
What's a typical value of max_num_pending_tx?
1424 Thanks, Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com
