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
