Hi Vipin & Tejun, Sorry for the late reply, I sent from a different email address than I intended. Please see my comments inline. On Thu, 4 Mar 2021 03:51:16 -0500, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Wed, Mar 03, 2021 at 10:22:03PM -0800, Vipin Sharma wrote: > > > I am trying to see if IOASIDs cgroup can also fit in this misc > > > controller as yet another resource type. > > > https://lore.kernel.org/linux-iommu/20210303131726.7a8cb169@jacob-builder/T/#u > > > However, unlike sev IOASIDs need to be migrated if the process is > > > moved to another cgroup. i.e. charge the destination and uncharge the > > > source. > > > > > > Do you think this behavior can be achieved by differentiating resource > > > types? i.e. add attach callbacks for certain types. Having a single > > > misc interface seems cleaner than creating another controller. > > > > I think it makes sense to add support for migration for the resources > > which need it. Resources like SEV, SEV-ES will not participate in > > migration and won't stop can_attach() to succeed, other resources which > > need migration will allow or stop based on their limits and capacity in > > the destination. > Sounds good. Perhaps some capability/feature flags for each resource such that different behavior can be accommodated? Could you please include me in your future posting? I will rebase on yours. > Please note that cgroup2 by and large don't really like or support charge > migration or even migrations themselves. We tried that w/ memcg on cgroup1 > and it turned out horrible. The expected usage model as decribed in the > doc is using migration to seed a cgroup (or even better, use the new > clone call to start in the target cgroup) and then stay there until exit. > All existing controllers assume this usage model and I'm likely to nack > deviation unless there are some super strong justifications. > Thank you so much for the pointers. Just to be clear, you meant 1. Use clone3 CLONE_INTO_CGROUP to put the child into a different cgroup. 2. Do not support migration of the parent (existing proc) Thanks, Jacob
