On Fri, Jun 03, 2022 at 12:52:27PM -0700, Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > Good catch. I get confused between cgrp->subsys and > task->cgroups->subsys sometimes because of different fallback > behavior. IIUC cgrp->subsys should have NULL if the memory controller > is not enabled (no nearest ancestor fallback), and hence I can use > memory_subsys_enabled() that I defined just above task_memcg() to test > for this (I have no idea why I am not already using it here). Is my > understanding correct? You're correct, css_set (task->cgroups) has a css (memcg) always defined (be it root only (or even a css from v1 hierarchy but that should not relevant here)). A particular cgroup can have the css set to NULL. When I think about your stats collecting example now, task_memcg() looks more suitable to achieve proper hierarchical counting in the end (IOW you'd lose info from tasks who don't reside in memcg-enabled leaf). (It's just that task_memcg won't return NULL. Unless the kernel is compiled without memcg support completely, which makes me think how do the config-dependent values propagate to BPF programs?) Thanks, Michal
