Each CPU-specific and unbound kworker kthread conforms to a particular
naming scheme. However, this does not extend to the rescuer kworker.
At present, a rescuer kworker is simply named according to its
workqueue's name. This can be cryptic.
From the context of user-mode, it can be useful to identify a rescuer
kworker since their CPU affinity cannot be modified and their initial
CPU assignment can be safely ignored. By design a rescuer kworker can
run anywhere and only processes work items in an emergency situation.
This patch modifies a rescuer to follow the kworker naming scheme.
The "r" and "-" is indicative of a rescuer and its workqueue's
name respectively e.g. "kworker/r-ext4-rsv-conver".
Signed-off-by: Aaron Tomlin <[email protected]>
---
kernel/workqueue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 02a8f402eeb5..d9bb375b8d02 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4599,7 +4599,7 @@ static int init_rescuer(struct workqueue_struct *wq)
}
rescuer->rescue_wq = wq;
- rescuer->task = kthread_create(rescuer_thread, rescuer, "%s", wq->name);
+ rescuer->task = kthread_create(rescuer_thread, rescuer, "kworker/r-%s", wq->name);
if (IS_ERR(rescuer->task)) {
ret = PTR_ERR(rescuer->task);
pr_err("workqueue: Failed to create a rescuer kthread for wq \"%s\": %pe",
--
2.39.1
On Mon, Aug 07, 2023 at 11:06:37PM +0100, Aaron Tomlin wrote:
> Each CPU-specific and unbound kworker kthread conforms to a particular
> naming scheme. However, this does not extend to the rescuer kworker.
> At present, a rescuer kworker is simply named according to its
> workqueue's name. This can be cryptic.
>
> From the context of user-mode, it can be useful to identify a rescuer
> kworker since their CPU affinity cannot be modified and their initial
I'm not necessarily against the rename but you can't, or at least shouldn't,
modify the cpu affinity of any workqueue worker. You don't know what that
worker is going to be executing even at the moment when the cpu affinity
change is committed, let alone in any future. Can you please drop that part
from the patch description? It doesn't make a lot of sense.
Thanks.
--
tejun
> I'm not necessarily against the rename but you can't, or at least
> shouldn't, modify the cpu affinity of any workqueue worker. You don't
> know what that worker is going to be executing even at the moment when
> the cpu affinity change is committed, let alone in any future. Can you
> please drop that part from the patch description? It doesn't make a lot
> of sense.
Hi Tejun,
Understood - will do. Initially, I wanted to stress the point that
user-mode should not pay any attention to a rescuer kworker's CPU affinity
since by design it can run on any possible CPU.
According to housekeeping_setup() and workqueue_init_early(), if I
understand correctly, when kernel parameter nohz_full is set then each
unbound kworker is not permitted to execute on any CPU in the specified
range i.e. the unbound workqueue cpumask is set based on the housekeeping
cpumask only. So, that's good enough.
Kind regards,
--
Aaron Tomlin