[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <kuxzxh4r6fapb5tjbhvm7fsw7p2g6vlasdv46j2ggedmbbsec2@zgt445q4oob2>
Date: Thu, 15 May 2025 11:45:30 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Usama Arif <usamaarif642@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
hannes@...xchg.org, shakeel.butt@...ux.dev, riel@...riel.com,
ziy@...dia.com, laoar.shao@...il.com, baolin.wang@...ux.alibaba.com,
npache@...hat.com, ryan.roberts@....com, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH 1/6] prctl: introduce PR_THP_POLICY_DEFAULT_HUGE for the
process
* David Hildenbrand <david@...hat.com> [250515 10:44]:
> On 15.05.25 16:40, Lorenzo Stoakes wrote:
> > Overall I feel this series should _DEFINITELY_ be an RFC. This is pretty
> > outlandish stuff and needs discussion.
> >
> > You're basically making it so /sys/kernel/mm/transparent_hugepage/enabled =
> > never is completely ignored and overridden.
>
> I thought I made it very clear during earlier discussions that never means
> never.
I also thought so, but the comments later made here [1] seem to
contradict that?
It seems "never" means "default_no" and not actually "never"?
Maybe the global/system toggles need to affect the state of each other?
That is, if /sys/kernel/mm/transparent_hugepage/enabled is never and you
set /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled to
madvise, it should not leave /sys/kernel/mm/transparent_hugepage/enabled
as never.
I just don't see "never" as the shutoff of the feature that I would
expect if it is overwritten by another enabled setting?
Obviously the need exists for a usecase of thp setting being inherited
as this is the 3rd(?) attempt at it.
We have control groups for resource control. We have decided THP is not
a resource but a policy (right?) and policies don't belong in control
groups.
I'm fine with this, btw. I just do see the similarities in the
inheritance above and the control group layout. Also, the cgroups name
doesn't exactly limit the control to resources.
I agree with Lorenzo that discussion is needed because navigating what
we have now is difficult to understand and it's going to be difficult to
make any additions understandable.
Thanks,
Liam
[1]. https://lore.kernel.org/all/97702ff0-fc50-4779-bfa8-83dc42352db1@redhat.com/
Powered by blists - more mailing lists