On Thu, Sep 8, 2022 at 1:01 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > > On Wed, Sep 07, 2022 at 09:27:09AM -0700, Alexei Starovoitov wrote: > > On Wed, Sep 7, 2022 at 9:18 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > > > > > > Hello, > > > > > > On Wed, Sep 07, 2022 at 09:13:09AM -0700, Alexei Starovoitov wrote: > > > > Hmm. We discussed this option already. We definitely don't want > > > > to introduce an uapi knob that will allow anyone to skip memcg > > > > accounting today and in the future. > > > > > > cgroup.memory boot parameter is how memcg provides last-resort workarounds > > > for this sort of problems / regressions while they're being addressed. It's > > > not a dynamically changeable or programmable thing. Just a boot time > > > opt-out. That said, if you don't want it, you don't want it. > > > > ahh. boot param. > > Are you suggesting a global off switch ? Like nosocket and nokmem. > > That would be a different story. > > Need to think more about it. It could be ok. > > Yeah, nobpf or sth like that. An equivalent cgroup.memory parameter. > It may be a useful feature for some cases, but it can't help container users. The memcg works well to limit the non-pinned bpf-map, that's the reason why we, a container user, switch to memcg-based bpf charging. Our goal is to make it also work for pinned bpf-map. That said, your proposal may be a useful feature, but it should be another different patchset. -- Regards Yafang
