From: Brian Norris <briannorris@chromium.org>
To: Pin-yen Lin <treapking@chromium.org>
Cc: Kalle Valo <kvalo@kernel.org>,
Amitkumar Karwar <amitkarwar@gmail.com>,
Ganapathi Bhat <ganapathi017@gmail.com>,
Sharvari Harisangam <sharvari.harisangam@nxp.com>,
Xinming Hu <huxinming820@gmail.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] wifi: mwifiex: Replace RX workqueues with kthreads
Date: Mon, 12 Jun 2023 16:47:17 -0700 [thread overview]
Message-ID: <ZIeuhU/vnoL1yWmQ@google.com> (raw)
In-Reply-To: <CAEXTbpdDsoghsxbJqszx0OWWw1o9D8p9f_9-4OgOM-a-w7OzSA@mail.gmail.com>
Hi,
Thanks Pin-yen for most of the investigation here and for pushing the
patch. With some additional information though, I might suggest *not*
landing this patch at the moment. More details appended:
On Sat, Jun 10, 2023 at 01:41:51AM +0800, Pin-yen Lin wrote:
> I realized that I might have over-simplified the background and the
> impact of this patch...
>
> The short answer to the question is that the throughput improved from
> 100 mbps to 180 mbps. The test was run on ChromeOS's v5.15 kernel
> fork. More detailed test setting is mentioned in [1].
>
> However, the throughput of the same test case on our v4.19 kernel is
> 320 mbps. That is, we observed a 320 mbps --> 100 mbps regression when
> we tried to update the kernel version. This patch is more like a
> mitigation of the regression. It improves the throughput, even though
> it is still not as good as the older kernel.
>
> That being said, this patch does improve the throughput, so we think
> this patch can be landed into the mainline kernel.
>
> Best regards,
> Pin-yen
>
> [1]: https://lore.kernel.org/all/ZFvpJb9Dh0FCkLQA@google.com/
I (we?) was optimistic this would be an improvement (or at least, no
worse) due to some of the reasoning at [1]. And, the work here is just a
single work item, queued repeatedly to the same unbound workqueue. So
conceptually, it shouldn't be much different than a kthread_worker,
except for scheduler details -- where again, we'd think this should be
an improvement, as the scheduler would now better track load for the
task (mwifiex RX) in question.
But additional testing on other mwifiex-based systems (RK3399 + PCIE
8997) showed the inverse: some throughput drops on similar benchmarks,
from 110 Mbps to 80 Mbps. (Frankly, both numbers are significantly below
where we might like...)
Considering we still don't have a full explanation for all the
performance differences we've been seeing (on either test platform), and
that at least one of our platforms showed a (smaller) regression, I
think we might want to do more research before committing to this.
Brian
next prev parent reply other threads:[~2023-06-12 23:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-09 10:35 [PATCH] wifi: mwifiex: Replace RX workqueues with kthreads Pin-yen Lin
2023-06-09 10:41 ` Kalle Valo
2023-06-09 17:41 ` Pin-yen Lin
2023-06-12 23:47 ` Brian Norris [this message]
2023-06-13 5:12 ` 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=ZIeuhU/vnoL1yWmQ@google.com \
--to=briannorris@chromium.org \
--cc=amitkarwar@gmail.com \
--cc=ganapathi017@gmail.com \
--cc=huxinming820@gmail.com \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=sharvari.harisangam@nxp.com \
--cc=treapking@chromium.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.