[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL1PR11MB54783384845A2BCFEE305DA1FF089@BL1PR11MB5478.namprd11.prod.outlook.com>
Date: Wed, 23 Jun 2021 05:34:15 +0000
From: "Zhang, Qiang" <Qiang.Zhang@...driver.com>
To: Lai Jiangshan <jiangshanlai@...il.com>
CC: Tejun Heo <tj@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] workqueue: set the rescuer worker that belong to
freezable wq is freezable
________________________________________
From: Lai Jiangshan <jiangshanlai@...il.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@...driver.com> wrote:
>
> From: Zqiang <qiang.zhang@...driver.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@...driver.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
>
Powered by blists - more mailing lists