Subject: Re: [PATCH 02/13] wifi: mwifiex: Use default @max_active for workqueues

From: Brian Norris <[email-masked]>
Date: Wed, 10 May 2023 11:09:55 -0700

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 <[email-masked]>
> Cc: Amitkumar Karwar <[email-masked]>
> Cc: Ganapathi Bhat <[email-masked]>
> Cc: Sharvari Harisangam <[email-masked]>
> Cc: Xinming Hu <[email-masked]>
> Cc: Kalle Valo <[email-masked]>
> Cc: "David S. Miller" <[email-masked]>
> Cc: Eric Dumazet <[email-masked]>
> Cc: Jakub Kicinski <[email-masked]>
> Cc: Paolo Abeni <[email-masked]>
> Cc: [email-masked]
> Cc: [email-masked]
> Cc: [email-masked]

Reviewed-by: Brian Norris <[email-masked]>

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