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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <63f50032-9df6-44aa-4b69-9b7882ee416d@linux.alibaba.com>
Date:   Sat, 9 Oct 2021 22:24:40 +0800
From:   Baolin Wang <baolin.wang@...ux.alibaba.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Support hugetlb charge moving at task migration



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.