Messages in this thread | | | Date | Wed, 8 May 2024 12:45:09 +0800 | Subject | Re: [PATCH 5/8] mm: shmem: add multi-size THP sysfs interface for anonymous shmem | From | Baolin Wang <> |
| |
On 2024/5/7 18:52, Ryan Roberts wrote: > On 06/05/2024 09:46, Baolin Wang wrote: >> To support the use of mTHP with anonymous shmem, add a new sysfs interface >> 'shmem_enabled' in the '/sys/kernel/mm/transparent_hugepage/hugepages-kB/' >> directory for each mTHP to control whether shmem is enabled for that mTHP, >> with a value similar to the top level 'shmem_enabled', which can be set to: >> "always", "inherit (to inherit the top level setting)", "within_size", "advise", >> "never", "deny", "force". These values follow the same semantics as the top >> level, except the 'deny' is equivalent to 'never', and 'force' is equivalent >> to 'always' to keep compatibility. > > We decided at [1] to not allow 'force' for non-PMD-sizes. > > [1] > https://lore.kernel.org/linux-mm/533f37e9-81bf-4fa2-9b72-12cdcb1edb3f@redhat.com/ > > However, thinking about this a bit more, I wonder if the decision we made to > allow all hugepages-xxkB/enabled controls to take "inherit" was the wrong one. > Perhaps we should have only allowed the PMD-sized enable=inherit (this is just > for legacy back compat after all, I don't think there is any use case where > changing multiple mTHP size controls atomically is actually useful). Applying
Agree. This is also our usage of 'inherit'.
> that pattern here, it means the top level can always take "force" without any > weird error checking. And we would allow "force" on the PMD-sized control but > not on the others - again this is easy to error check. > > Does this pattern make more sense? If so, is it too late to change > hugepages-xxkB/enabled interface?
IMO, this sounds reasonable to me. Let's see what others think, David?
| |