On 2021/10/8 19:55, Michal Hocko wrote:
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.
OK.
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
Yes.
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.
OK. I see. Thanks.
