Thanks for taking a look at this!
On Fri, Jun 3, 2022 at 9:23 AM Michal Koutný <mkoutny@xxxxxxxx> wrote:
>
> On Fri, May 20, 2022 at 01:21:33AM +0000, Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote:
> > +#define CGROUP_PATH(p, n) {.name = #n, .path = #p"/"#n}
> > +
> > +static struct {
> > + const char *name, *path;
>
> Please unify the order of path and name with the macro (slightly
> confusing ;-).
Totally agree, will do.
>
> > +SEC("tp_btf/mm_vmscan_memcg_reclaim_end")
> > +int BPF_PROG(vmscan_end, struct lruvec *lruvec, struct scan_control *sc)
> > +{
> > [...]
> > + struct cgroup *cgrp = task_memcg(current);
> > [...]
> > + /* cgrp may not have memory controller enabled */
> > + if (!cgrp)
> > + return 0;
>
> Yes, the controller may not be enabled (for a cgroup).
> Just noting that the task_memcg() implementation will fall back to
> root_mem_cgroup in such a case (or nearest ancestor), you may want to
> use cgroup_ss_mask() for proper detection.
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?
>
> Regards,
> Michal
