lkml.org 
[lkml]   [2022]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-03-21 18:03    [W:0.072 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site