[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZyHwgjK8t8kWkm9E@tiehlicka>
Date: Wed, 30 Oct 2024 09:38:26 +0100
From: Michal Hocko <mhocko@...e.com>
To: gutierrez.asier@...wei-partners.com
Cc: 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, stepanov.anatoly@...wei.com,
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
Subject: Re: [RFC PATCH 0/3] Cgroup-based THP control
On Wed 30-10-24 16:33:08, gutierrez.asier@...wei-partners.com wrote:
> From: Asier Gutierrez <gutierrez.asier@...wei-partners.com>
>
> Currently THP modes are set globally. It can be an overkill if only some
> specific app/set of apps need to get benefits from THP usage. Moreover, various
> apps might need different THP settings. Here we propose a cgroup-based THP
> control mechanism.
>
> THP interface is added to memory cgroup subsystem. Existing global THP control
> semantics is supported for backward compatibility. When THP modes are set
> globally all the changes are propagated to memory cgroups. However, when a
> particular cgroup changes its THP policy, the global THP policy in sysfs remains
> the same.
Do you have any specific examples where this would be benefitial?
> New memcg files are exposed: memory.thp_enabled and memory.thp_defrag, which
> have completely the same format as global THP enabled/defrag.
>
> Child cgroups inherit THP settings from parent cgroup upon creation. Particular
> cgroup mode changes aren't propagated to child cgroups.
So this breaks hierarchical property, doesn't it? In other words if a
parent cgroup would like to enforce a certain policy to all descendants
then this is not really possible.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists