[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZFvfYK-u8suHjPFw@slm.duckdns.org>
Date: Wed, 10 May 2023 08:16:00 -1000
From: Tejun Heo <tj@...nel.org>
To: Brian Norris <briannorris@...omium.org>
Cc: jiangshanlai@...il.com, linux-kernel@...r.kernel.org,
kernel-team@...a.com, Amitkumar Karwar <amitkarwar@...il.com>,
Ganapathi Bhat <ganapathi017@...il.com>,
Sharvari Harisangam <sharvari.harisangam@....com>,
Xinming Hu <huxinming820@...il.com>, Kalle Valo <kvalo@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 02/13] wifi: mwifiex: Use default @max_active for
workqueues
Hello,
On Wed, May 10, 2023 at 11:09:55AM -0700, Brian Norris wrote:
> 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.
Yeah, a future patch is gonna change the semantics a bit and I'll update the
doc to be clearer.
> 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.
Can you elaborate the performance problem you're seeing? I'm working on a
major update for workqueue to improve its locality behavior, so if you're
experiencing issues on CPUs w/ multiple L3 caches, it'd be a good test case.
Thanks.
--
tejun
Powered by blists - more mailing lists