On Fri, 28 Dec 2018, Michal Hocko wrote: > > > And if the > > > application later enables THP by the prctl then existing mappings would > > > never get the THP enabled status back. > > > > > > > If do prctl(PR_SET_THP_DISABLE, 0) later to clear the disabling, my patch > > is a no-op, smaps reports whether the vma is eligible for hugepages > > depending on MADV_HUGEPAGE or not, which also matches the implementation > > of transparent_hugepage_enabled(). > > > > Where is the issue? > > How do you clear the NOHUGE flag in pre-existing vmas to the original > value? You cannot tell vmas with explicit NOHUGE flag set by madvise and > those reported due the prctl value. > > In other words. Consider a CRIU-like usecase when you snapshot an application > at some point of time, restore it and let the application run again > and it does (PR_SET_THP_DISABLE, 0). All the pre-existing vmas will > retain their NOHUGE vma flag and as such will be excluded from THP. > Application will behave differently from before the snaphost which looks > like a bug, right? > Smaps reveals the state of each vma at the moment it is read, not the future, this has always been the case before and after the broken commit; it's not intended to be something that can specify "thp is currently disabled, but if we did prctl(PR_SET_THP_DISABLE, 0), this vma has done madvise(MADV_HUGEPAGE), and we are on a thp enabled == madvise host, so it would be eligible for thp."
