All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: kvalo@qca.qualcomm.com, linux-wireless@vger.kernel.org,
	ath10k@lists.infradead.org, yiboz@codeaurora.org,
	Erik Stromdahl <erik.stromdahl@gmail.com>
Subject: Re: [PATCH] ath10k: remove iteration in wake_tx_queue
Date: Wed, 25 Sep 2019 05:41:07 +0000 (UTC)	[thread overview]
Message-ID: <20190925054107.935786119D@smtp.codeaurora.org> (raw)
In-Reply-To: <20190327162906.6010-1-erik.stromdahl@gmail.com>

Erik Stromdahl <erik.stromdahl@gmail.com> wrote:

> Iterating the TX queue and thereby dequeuing all available packets in the
> queue could result in performance penalties on some SMP systems.
> 
> The reason for this is most likely that the per-ac lock (active_txq_lock)
> in mac80211 will be held by the CPU iterating the current queue.
> 
> This will lock up other CPUs trying to push new messages on the TX
> queue.
> 
> Instead of iterating the queue we fetch just one packet at the time,
> resulting in minimal starvation of the other CPUs.
> 
> Reported-by: Yibo Zhao <yiboz@codeaurora.org>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>

Like others, I'm not convinced about this either. To me it looks like a quick
workaround instead of properly investigating, and fixing, the root cause. To my
understanding the throughput dip was caused by this commit:

e3148cc5fecf ath10k: fix return value check in wake_tx_q op

So to me it feels like the issue has been there all along, just hidden, and the
fix above just exposed it.

-- 
https://patchwork.kernel.org/patch/10873753/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


  parent reply	other threads:[~2019-09-25  5:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-27 16:29 [PATCH] ath10k: remove iteration in wake_tx_queue Erik Stromdahl
2019-03-27 16:29 ` Erik Stromdahl
2019-03-27 17:49 ` Peter Oh
2019-03-27 17:49   ` Peter Oh
2019-03-29  7:47   ` Erik Stromdahl
2019-03-29  7:47     ` Erik Stromdahl
2019-04-01 12:17     ` Yibo Zhao
2019-04-01 12:17       ` Yibo Zhao
2019-04-01 11:05 ` Toke Høiland-Jørgensen
2019-04-01 11:05   ` Toke Høiland-Jørgensen
2019-04-16 18:54   ` Erik Stromdahl
2019-04-16 18:54     ` Erik Stromdahl
2019-04-16 19:07     ` Toke Høiland-Jørgensen
2019-04-16 19:07       ` Toke Høiland-Jørgensen
2019-04-17 13:29       ` Erik Stromdahl
2019-04-17 13:29         ` Erik Stromdahl
2019-04-26  7:07         ` Kalle Valo
2019-04-26  7:07           ` Kalle Valo
2019-09-25  5:41 ` Kalle Valo [this message]
2019-09-25  5:41 ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190925054107.935786119D@smtp.codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=erik.stromdahl@gmail.com \
    --cc=kvalo@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=yiboz@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.