Re: [PATCH 0/2] Support hugetlb charge moving at task migration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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. 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.

This patch set adds hugetlb cgroup charge moving when
migrate tasks among cgroups, which are based on the memcg charge moving.

Memcg charge moving has shown some problems over time and hence this is
not part of cgroup v2 interface anymore. Even for cgroup v1 this has

Sorry, I missed this part, could you elaborate on the issues? I can have a
close look about the problems of memcg charge moving.

The operation is quite expensive. Synchronization with charging is not
trivial. I do not have the full list handy but you can search the
mm mailing list archives for more information.

Sure, thanks.


been an opt-in. I do not see anything like that in this patch series.
Why should all existing workloads follow a different semantic during
task migration now?

But I think it is reasonable for some cases moving the old charging to the
new cgroup when task migration. Maybe I can add a new hugetlb cgroup file to
control if need this or not?

It would be good to describe those use cases and why they really need
this. Because as things stand now, the charge migration is not supported
in cgroup v2 for memory cgroup controller and there are no plans to add
the support so it would be quite unexpected that hugetlb controller
would behave differently. And cgroup v1 is considered legacy and new
features are ususally not added as there is a hope to move users to v2.

OK, understood. Seems you have a strong opinion that it is unnecessary to introduce this feature for cgroup v1 now, then I will drop this patch set. Thanks for your input.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux