[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZySEvmfwpT_6N97I@tiehlicka>
Date: Fri, 1 Nov 2024 08:35:26 +0100
From: Michal Hocko <mhocko@...e.com>
To: Stepanov Anatoly <stepanov.anatoly@...wei.com>
Cc: Gutierrez Asier <gutierrez.asier@...wei-partners.com>,
akpm@...ux-foundation.org, david@...hat.com, ryan.roberts@....com,
baohua@...nel.org, willy@...radead.org, peterx@...hat.com,
hannes@...xchg.org, hocko@...nel.org, roman.gushchin@...ux.dev,
shakeel.butt@...ux.dev, muchun.song@...ux.dev,
cgroups@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
alexander.kozhevnikov@...wei-partners.com, guohanjun@...wei.com,
weiyongjun1@...wei.com, wangkefeng.wang@...wei.com,
judy.chenhui@...wei.com, yusongping@...wei.com,
artem.kuzin@...wei.com, kang.sun@...wei.com,
nikita.panov@...wei-partners.com
Subject: Re: [RFC PATCH 0/3] Cgroup-based THP control
On Thu 31-10-24 17:37:12, Stepanov Anatoly wrote:
> If we consider the inheritance approach (prctl + launcher), it's fine until we need to change
> THP mode property for several tasks at once, in this case some batch-change approach needed.
I do not follow. How is this any different from a single process? Or do
you mean to change the mode for an already running process?
> if, for example, process_madvise() would support task recursive logic, coupled with kind of
> MADV_HUGE + *ITERATE_ALL_VMA*, it would be helpful.
> In this case, the orchestration will be much easier.
Nope, process_madvise is pidfd based interface and making it recursive
seems simply impossible for most operations as the address space is very
likely different in each child process.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists