[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c27c755c188f48e8b2ab60868b0e0173@realtek.com>
Date: Tue, 18 Nov 2025 00:41:09 +0000
From: Ping-Ke Shih <pkshih@...ltek.com>
To: Marco Crivellari <marco.crivellari@...e.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
Tejun Heo
<tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
Frederic Weisbecker
<frederic@...nel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Michal Hocko <mhocko@...e.com>
Subject: RE: [PATCH 1/2] wifi: rtlwifi: add WQ_PERCPU to alloc_workqueue users
Marco Crivellari <marco.crivellari@...e.com> wrote:
> Hi,
>
> On Mon, Nov 17, 2025 at 1:53 AM Ping-Ke Shih <pkshih@...ltek.com> wrote:
> > [...]
> >
> > I think this driver should use WQ_UNBOUND as well as another patch in this
> > patchset.
> >
> >
> > I feel most user scenarios should be WQ_UNBOUND. Could you share which case
> > uses WQ_PERCPU?
>
> I think a typical scenario is when per-cpu variables are used.
> But this is not the case here, for both the patches.
>
> So yes, unless there is the need to have the item scheduled on the same CPU,
> this can be converted to WQ_UNBOUND.
>
> I did the same for other series in other subsystems. If you want, I
> can send the v2
> with the change.
Please send v2 with WQ_UNBOUND. Thanks.
Powered by blists - more mailing lists