Messages in this thread | | | Date | Wed, 10 May 2023 11:09:55 -0700 | From | Brian Norris <> | Subject | Re: [PATCH 02/13] wifi: mwifiex: Use default @max_active for workqueues |
| |
On Mon, May 08, 2023 at 03:50:21PM -1000, Tejun Heo wrote: > These workqueues only host a single work item and thus doen't need explicit > concurrency limit. Let's use the default @max_active. This doesn't cost > anything and clearly expresses that @max_active doesn't matter. > > Signed-off-by: Tejun Heo <tj@kernel.org> > Cc: Amitkumar Karwar <amitkarwar@gmail.com> > Cc: Ganapathi Bhat <ganapathi017@gmail.com> > Cc: Sharvari Harisangam <sharvari.harisangam@nxp.com> > Cc: Xinming Hu <huxinming820@gmail.com> > Cc: Kalle Valo <kvalo@kernel.org> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Eric Dumazet <edumazet@google.com> > Cc: Jakub Kicinski <kuba@kernel.org> > Cc: Paolo Abeni <pabeni@redhat.com> > Cc: linux-wireless@vger.kernel.org > Cc: netdev@vger.kernel.org > Cc: linux-kernel@vger.kernel.org
Reviewed-by: Brian Norris <briannorris@chromium.org>
I'll admit, the workqueue documentation sounds a bit like "max_active == 1 + WQ_UNBOUND" is what we want ("one work item [...] active at any given time"), but that's more of my misunderstanding than anything -- each work item can only be active in a single context at any given time, so that note is talking about distinct (i.e., more than 1) work items.
While I'm here: we're still debugging what's affecting WiFi performance on some of our WiFi systems, but it's possible I'll be turning some of these into struct kthread_worker instead. We can cross that bridge (including potential conflicts) if/when we come to it though.
Thanks, Brian
| |