On Fri 28-12-18 11:15:20, David Rientjes wrote: > 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? In other words exactly the same type of bug which has been solved by reimplemention of the prctl from using def_flags to use a proper per mm flag. Is it more clear now? -- Michal Hocko SUSE Labs
