Re: [PATCH] firewire: core: add WQ_PERCPU to alloc_workqueue users
Marco Crivellari <[email protected]> Mon, 10 Nov 2025 11:04:31 +0100
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.firewire.devel |
|---|---|
| Message-ID | <CAAofZF7wY9OYNSJyLsWSPczPZvfPHGtRomryTsbONQ--pOy=-g@mail.gmail.com> |
On Sat, Nov 8, 2025 at 3:54 AM Takashi Sakamoto <[email protected]> wrote: > [...] > > diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c > > index c65f491c54d0..c15dbe882cbe 100644 > > --- a/drivers/firewire/core-transaction.c > > +++ b/drivers/firewire/core-transaction.c > > @@ -1437,7 +1437,8 @@ static int __init fw_core_init(void) > > { > > int ret; > > > > - fw_workqueue = alloc_workqueue("firewire", WQ_MEM_RECLAIM, 0); > > + fw_workqueue = alloc_workqueue("firewire", WQ_MEM_RECLAIM | WQ_PERCPU, > > + 0); > > if (!fw_workqueue) > > return -ENOMEM; > > As far as I know, there is no specific reason to use per-cpu workqueue > for this purpose in this subsystem. I believe that using unbound workqueue > would be more beneficial, since the workqueue users just operate chained > 1394 OHCI DMA descriptor over system memory for asynchronous > communication. > > Would it be acceptable for you to add WQ_UNBOUND flag to the workqueue? > If so, I can prepare a patch for the next merge window. Hi Takashi, Yes looking at the code it makes sense to have this workqueue unbound. If you want, it is not a problem for me to send a v2 with the change, let me know. Thanks! -- Marco Crivellari L3 Support Engineer, Technology & Product