Messages in this thread | | | Date | Mon, 21 Mar 2022 07:02:45 -1000 | From | Tejun Heo <> | Subject | Re: [PATCH v3 (repost)] workqueue: Warn flushing of kernel-global workqueues |
| |
Hello,
On Sun, Mar 20, 2022 at 03:06:30PM +0900, Tetsuo Handa wrote: ... > What alternative are you expecting? We already have alternatives. > This change (replacing system_wq with module's local workqueue as > an example) is a matter of doing > > (1) add > > some_workqueue_for_that_module = alloc_workqueue("some_name", 0, 0); > > into module's __init function. > > (2) add > > destroy_workqueue(some_workqueue_for_that_module); > > into module's __exit function. > > (3) replace > > schedule_work(some_work); > > with > > queue_work(some_workqueue_for_that_module, some_work); > > throughout that module. > > (4) replace > > flush_scheduled_work(); > > with > > flush_workqueue(some_workqueue_for_that_module); > > throughout that module. > > if flush_scheduled_work() cannot be avoided.
I'm willing to bet that the majority of the use cases can be converted to use flush_work() and that'd be the preference. We need a separate workqueue iff the flush requrement is complex (e.g. there are multiple dynamic work items in flight which need to be flushed together) or the work items needs some special attributes (such as MEM_RECLAIM or HIGHPRI) which don't apply to the system_wq users in the first place.
Thanks.
-- tejun
| |