On Thu, May 15, 2025 at 05:57:57PM +0200, David Hildenbrand wrote: > On 15.05.25 17:45, Liam R. Howlett wrote: > > * David Hildenbrand <david@xxxxxxxxxx> [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's ... complicated. > > > > > It seems "never" means "default_no" and not actually "never"? > > We should consider these system toggles a single set of toggles that define a > state, and not individual toggles that overwrite each other. > > If you say > /sys/kernel/mm/transparent_hugepage/enabled = never > and > /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled = always > > instead of the *default* > > /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled = inherit > > the admin explicitly stats "I want the system behavior for 2048kB not to be configured using > /sys/kernel/mm/transparent_hugepage/enabled". That's an admin decision, not a > per-process overwrite or whatever. > > > > > > 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 recall we discussed that, but there was also a catch to that. :( > > -- > Cheers, > > David / dhildenb > Did we document all this? :) It'd be good to be super explicit about these sorts of 'dependency chains'.
