Hello, On Sat, Mar 13, 2021 at 08:57:01AM -0800, Jacob Pan wrote: > Isn't PIDs controller doing the charge/uncharge? I was under the impression > that each resource can be independently charged/uncharged, why it affects > other resources? Sorry for the basic question. Yeah, PID is an exception as we needed the initial migration to seed new cgroups and it gets really confusing with other ways to observe the processes - e.g. if you follow the original way of creating a cgroup, forking and then moving the seed process into the target cgroup, if we don't migrate the pid charge together, the numbers wouldn't agree and the seeder cgroup may end up running out of pids if there are any restrictions. > I also didn't quite get the limitation on cgroup v2 migration, this is much > simpler than memcg. Could you give me some pointers? Migration itself doesn't have restrictions but all resources are distributed on the same hierarchy, so the controllers are supposed to follow the same conventions that can be implemented by all controllers. > BTW, since the IOASIDs are used to tag DMA and bound with guest process(mm) > for shared virtual addressing. fork() cannot be supported, so I guess clone > is not a solution here. Can you please elaborate what wouldn't work? The new spawning into a new cgroup w/ clone doesn't really change the usage model. It's just a neater way to seed a new cgroup. If you're saying that the overall usage model doesn't fit the needs of IOASIDs, it likely shouldn't be a cgroup controller. Thanks. -- tejun
