Messages in this thread Patch in this message | | | From | "Zhang, Qiang" <> | Subject | Re: [PATCH v2] workqueue: set the rescuer worker that belong to freezable wq is freezable | Date | Wed, 23 Jun 2021 05:34:15 +0000 |
| |
________________________________________ From: Lai Jiangshan <jiangshanlai@gmail.com> Sent: Wednesday, 23 June 2021 11:16 To: Zhang, Qiang Cc: Tejun Heo; Andrew Morton; LKML Subject: Re: [PATCH v2] workqueue: set the rescuer worker that belong to freezable wq is freezable
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Tue, Jun 22, 2021 at 8:42 PM <qiang.zhang@windriver.com> wrote: > > From: Zqiang <qiang.zhang@windriver.com> > > If the rescuer worker belong to freezable wq, when this wq is > frozen, the rescuer worker also need to be frozen.
>Hello, > >From my understanding, the wq subsystem doesn't use >set_freezable(), >try_to_freeze() families. For example, the worker_thread() >doesn't >use set_freezable(), neither do in your patch. If kthreads >in the wq subsystem need these functions, please let us know. > >The way the wq subsystem to freeze tasks is by >freeze_workqueues_begin() >and thaw_workqueues(). When WQs is requested for freezing, >they will stop activating work items. All the workers including >*rescuers* will be scheduled as TASK_IDLE when all the >activated work >items are processed and the whole wq subsystem is frozen >unless >there is any semantic change about TASK_IDLE V.S. "frozen". >(rescuers can also only process activated work items.)
Hello Lai My understanding is this: when the freeze_workqueues_begin() be called, this only set pwq->max_active is zero, it's just to prevent, after that when we queue the work again, we will put it in the pwq->delayed_works, but if there are still some work in the pool->worklist, the workers in pool are still handle work items, and the rescuer work may be also handle work items, until the work items is processed, the workers enters TASK_IDLE status. the rescuer worker is independent of workerpools , when the system freezing, freeze the rescuer worker directly without waiting for all workitems to be processed.
Thanks Qiang
> >Thanks >Lai
> > Signed-off-by: Zqiang <qiang.zhang@windriver.com> > --- > v1->v2: > use kthread_freezable_should_stop() replaces try_to_freeze(). > > kernel/workqueue.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > index 104e3ef04e33..dd7b78bdb7f1 100644 > --- a/kernel/workqueue.c > +++ b/kernel/workqueue.c > @@ -2476,6 +2476,9 @@ static int rescuer_thread(void *__rescuer) > * doesn't participate in concurrency management. > */ > set_pf_worker(true); > + > + if (wq->flags & WQ_FREEZABLE) > + set_freezable(); > repeat: > set_current_state(TASK_IDLE); > > @@ -2487,7 +2490,7 @@ static int rescuer_thread(void *__rescuer) > * @wq->maydays processing before acting on should_stop so that the > * list is always empty on exit. > */ > - should_stop = kthread_should_stop(); > + should_stop = kthread_freezable_should_stop(NULL); > > /* see whether any pwq is asking for help */ > raw_spin_lock_irq(&wq_mayday_lock); > -- > 2.25.1 >
| |