linux-kernel - Re: [PATCH] workqueue: show the latest function name in /proc/PID/{comm,stat,status}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <8A1F225D-714C-427C-A0ED-1DE5D93DEAD1@linux.dev>
Date: Fri, 16 May 2025 12:44:19 +0800
From: Muchun Song <muchun.song@...ux.dev>
To: Tejun Heo <tj@...nel.org>
Cc: Muchun Song <songmuchun@...edance.com>, jiangshanlai@...il.com,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: show the latest function name in /proc/PID/{comm,stat,status}



> On May 15, 2025, at 23:53, Tejun Heo <tj@...nel.org> wrote:
> 
> Hello, Muchun.
> 
> On Thu, May 15, 2025 at 12:05:23PM +0800, Muchun Song wrote:
>> Workqueues, such as system_unbound_wq, are shared across the system,
>> making it difficult to determine which tasks are being executed by
>> each worker. This patch improves clarity by displaying the latest
>> function name associated with each workqueue worker in the
>> /proc/PID/{comm,stat,status}. For example:
>> 
>> Before:
>>  # ps 64 67 68
>>  PID TTY STAT TIME COMMAND
>>  64  ?   I    0:00 [kworker/u34:0-events_unbound]
>>  67  ?   I    0:00 [kworker/u33:1-events_unbound]
>>  68  ?   I    0:00 [kworker/u33:2-events_unbound]
>> 
>> After:
>>  # ps 64 67 68
>>  PID TTY STAT TIME COMMAND
>>  64  ?   I    0:00 [kworker/u34:0-events_unbound:flush_memcg_stats_dwork]
>>  67  ?   I    0:00 [kworker/u33:1-events_unbound:flush_to_ldisc]
>>  68  ?   I    0:00 [kworker/u33:2-events_unbound:idle_cull_fn]
>> 
>> This change provides a clearer view of the tasks being performed by
>> each worker, enhancing system monitoring and debugging.
> 
> One worry I have about this is that these will likely be stale most of the
> time as kworkers are just sitting and waiting, and there's no connection
> between what a kworker ran before and what it's going to run next, so I'm
> unsure how useful the extra information is.

Hi Tejun,

Monitoring tools like atop can indeed record comm of processes. When we
encounter issues such as high CPU usage, these tools can help us identify
the problem. For instance, if kworkers are consuming most of the CPU, we
can use this information to pinpoint which specific function is using
the most CPU.

Another use case is when we use the isolcpus= command line option
to isolate CPUs, we want to make sure that no kworker threads run on
those CPUs. But sometimes, kworkers might still get scheduled there, causing latency
issues. By using this information, we can figure out which module's
function ran on the CPU before and then dig into the code to see how to
stop it from happening.


Muchun,
Thanks

> 
> Thanks.
> 
> -- 
> tejun