On Mon, Sep 16, 2019 at 4:23 PM Tejun Heo <[email protected]> wrote: > > Hello, Song. > > On Sat, Sep 14, 2019 at 03:02:51PM +0100, Song Liu wrote: > > I think we don't need a perfect identifier in this case. IIUC, the goal of > > I really don't want different versions of imperfect identifiers > proliferating. > > > this patchset is to map each sample with a cgroup name (or full path). > > To achieve this, we need > > > > 1. PERF_RECORD_CGROUP, that maps > > "64-bit number" => cgroup name/path > > 2. PERF_SAMPLE_CGROUP, that adds "64-bit number" to each sample. > > > > I call the id a "64-bit number" because it is not required to be a globally > > unique id. As long as it is consistent within the same perf-record session, > > we won't get any confusion. Since we add PERF_RECORD_CGROUP > > for each cgroup creation, we will map most of samples correctly even > > when the "64-bit number" is recycled within the same perf-record session. > > > > At the moment, I think ino is good enough for the "64-bit number" even > > for 32-bit systems. If we don't call it "ino" (just call it "cgroup_tag" or > > "cgroup_id", we can change it when kernfs provides a better 64-bit id. > > So, a firm nack on this direction. > > > About full path name: The user names the full path here. If the user gives > > two different workloads the same name/path, we really cannot change that. > > Reasonable users would be able to make sense from the full path. > > I don't see why we wanna be causing this avoidable problem to users.
Sharing some offline discussions with Tejun. ino in current kernfs is not a good unique ID for cgroup, because it doesn't increase monotonically. So we need to improve kernfs. For 64-bit, we can make the ino monotonic, and use it as the ID. For 32-bit, we need to make the ino monotonic. and use <ino> and <gen> as the 64-bit ID. Thanks, Song
