On Fri 08-10-21 17:17:12, Baolin Wang wrote: > > > On 2021/10/8 15:12, Michal Hocko wrote: > > On Thu 07-10-21 23:39:15, Baolin Wang wrote: > > > Hi Michal, > > > > > > (Sorry for late reply due to my holidays) > > > On 2021/9/30 18:46, Michal Hocko wrote: > > > > On Wed 29-09-21 18:19:26, Baolin Wang wrote: > > > > > Hi, > > > > > > > > > > Now in the hugetlb cgroup, charges associated with a task aren't moved > > > > > to the new hugetlb cgroup at task migration, which is odd for hugetlb > > > > > cgroup usage. > > > > > > > > Could you elaborate some more about the usecase and/or problems you see > > > > with the existing semantic? > > > > > > The problems is that, it did not check if the tasks can move to the new > > > hugetlb cgroup if the new hugetlb cgroup has a limitation, and the hugetlb > > > cgroup usage is incorrect when moving tasks among hugetlb cgroups. > > > > Could you be more specific please? What do you mean by cgroup usage is > > incorrect? Ideally could you describe your usecase? > > Sorry for confusing, what I mean is, when tasks from one hugetlb cgroup are > migrated to a new hugetlb cgroup, the new hugetlb cgroup's hugetlb page > usage is not increased accordingly. Which is a perferctly reasonable behavior as the memory has been consumed from the original cgroup and it will be freed there as well. Migrating to a new cgroup doesn't imply all the resources to be migrated as well. > The issue I found is just from my > testing for the hugetlb cgroup, and I think this is not resonable if we've > already set a hugetlb limitation for a cgroup, but we always ignore it when > tasks migration among hugetlb cgroups. I would like to learn more about why you consider this unreasonable. This will likely depend on the reason why you want/need to migrate task. If you want to move a task to completely new resource domain (read a completely different cgroup subtree) then I can imagine you want to leave all the resources but this will have problems with other resource controllers - e.g. memory cgroup v2 which doesn't allow charge migration either. -- Michal Hocko SUSE Labs