Re: [PATCH v3 (repost)] workqueue: Warn flushing of kernel-global workqueues

[Tejun Heo]

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