Messages in this thread | | | Date | Thu, 23 Nov 2023 14:21:36 +0300 | From | Dmitry Rokosov <> | Subject | Re: [PATCH v2 1/2] mm: memcg: print out cgroup name in the memcg tracepoints |
| |
Shakeel,
On Thu, Nov 23, 2023 at 11:45:10AM +0300, Dmitry Rokosov wrote: > On Thu, Nov 23, 2023 at 08:15:47AM +0000, Shakeel Butt wrote: > > On Thu, Nov 23, 2023 at 11:03:34AM +0300, Dmitry Rokosov wrote: > > [...] > > > > > + cgroup_name(memcg->css.cgroup, > > > > > + __entry->name, > > > > > + sizeof(__entry->name)); > > > > > > > > Any reason not to use cgroup_ino? cgroup_name may conflict and be > > > > ambiguous. > > > > > > I actually didn't consider it, as the cgroup name serves as a clear tag > > > for filtering the appropriate cgroup in the entire trace file. However, > > > you are correct that there might be conflicts with cgroup names. > > > Therefore, it might be better to display both tags: ino and name. What > > > do you think on this? > > > > > > > I can see putting cgroup name can avoid pre or post processing, so > > putting both are fine. Though keep in mind that cgroup_name acquires a > > lock which may impact the applications running on the system. > > Are you talking about kernfs_rename_lock? Yes, it's acquired each > time... Unfortunatelly, I don't know a way to save cgroup_name one time > somehow...
I delved deeper and realized that kernfs_rename_lock is a read-write lock, but it's a global one. While it's true that we only enable tracepoints during specific periods of the host's lifetime, the trace system is still a fast way to debug things. So, you're absolutely right, we shouldn't slow down the system unnecessarily.
Therefore, today I will prepare a new version with only the cgroup ino. Thank you for pointing that out to me!
-- Thank you, Dmitry
| |