Messages in this thread | | | From | Yafang Shao <> | Date | Sun, 3 Oct 2021 22:20:46 +0800 | Subject | Re: [PATCH 0/5] kthread: increase the size of kthread's comm |
| |
On Sun, Oct 3, 2021 at 11:41 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Wed, Sep 29, 2021 at 11:50:31AM +0000, Yafang Shao wrote: > > > That motivates me to do this improvement. > > > > This patch increases the size of ktread's comm from 16 to 24, which is > > the same with workqueue's. After this change, the name of kthread can be > > fully displayed in /proc/[pid]/comm, for example, > > > > rcu_tasks_kthread > > rcu_tasks_rude_kthread > > rcu_tasks_trace_kthread > > ecryptfs-kthread > > vfio-irqfd-cleanup > > ext4-rsv-conversion > > jbd2/nvme0n1p2-8 > > ... > > > > Because there're only a few of kthreads, so it won't increase too much > > memory consumption. > > That's a bloody massive overkill. If you care about /proc/*/comm, you > might want to take a look at the function that generates its contents: > > void proc_task_name(struct seq_file *m, struct task_struct *p, bool escape) > { > char tcomm[64]; > > if (p->flags & PF_WQ_WORKER) > wq_worker_comm(tcomm, sizeof(tcomm), p); > else > __get_task_comm(tcomm, sizeof(tcomm), p); > > if (escape) > seq_escape_str(m, tcomm, ESCAPE_SPACE | ESCAPE_SPECIAL, "\n\\"); > else > seq_printf(m, "%.64s", tcomm); > } > > Hint: it's not always p->comm verbatim...
Right, I found it. That's why I was wondering storing the kthread's comm in kthread_data.[1] But after Petr's suggestion, I find increasing the size of comm to 24 for COFNIG_BASE_FULL and keeping it as 16 for COFNIG_BASE_SMALL is a better solution.
[1]. https://lore.kernel.org/lkml/CALOAHbD3HUqUnjMYKX7NGwVWiS4K7OvS6uPNWucnOA5Cy3pn9w@mail.gmail.com/#t
-- Thanks Yafang
| |