[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <447be1eb-87df-6941-1e5c-db79918dc77b@oracle.com>
Date: Tue, 5 Oct 2021 20:55:47 +1100
From: imran.f.khan@...cle.com
To: Tejun Heo <tj@...nel.org>
Cc: jiangshanlai@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] workqueue: Introduce __show_worker_pool_state and
__show_workqueue_state.
On 5/10/21 3:42 am, Tejun Heo wrote:
> On Tue, Sep 28, 2021 at 08:31:06PM +1000, Imran Khan wrote:
>> Currently show_workqueue_state shows the state of all workqueues and of
>> all worker pools.
>> Divide it into more granular functions (__show_workqueue_state and
>> __show_worker_pool_state), that would show states of individual workqueues
>> and worker pools.
>
> But why is this change good? Are you building something on top later?
>
The main motive was to dump data pertaining to only that workqueue which
is being destroyed in destroy_workqueue.
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index cfae0c8d5e2e..e191646dd3e4 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4447,7 +4447,7 @@ void destroy_workqueue(struct workqueue_struct *wq)
raw_spin_unlock_irq(&pwq->pool->lock);
mutex_unlock(&wq->mutex);
mutex_unlock(&wq_pool_mutex);
- show_workqueue_state();
+ __show_workqueue_state(wq);
return;
}
raw_spin_unlock_irq(&pwq->pool->lock);
Please let me know if I am missing some information that may be helpful
here and can be obtained only by dumping the states of other workqueues.
Then while going through the code, it seemed better to break
show_workqueue_state into more granular entities which can be used later
for cases such as one mentioned above.
Thanks for reviewing this.
-- Imran
> Thanks.
>
Powered by blists - more mailing lists