On Fri, 28 Dec 2018, Michal Hocko wrote: > > > > > I'm not interested in having a 100 email thread about this when a clear > > > > > and simple fix exists that actually doesn't break user code. > > > > > > > > You are breaking everybody who really wants to query MADV_NOHUGEPAGE > > > > status by this flag. Is there anybody doing that? > > > > > > Yes. > > > > > > https://github.com/checkpoint-restore/criu/blob/v3.11/criu/proc_parse.c#L143 > > > > Ugh. So the regression fix causes a regression? > > Yes. The patch from David will hardcode the nohugepage vm flag if the > THP was disabled by the prctl at the time of the snapshot. By snapshot, you mean smaps is read by userspace. This matches the implementation of transparent_hugepage_enabled(): PR_SET_THP_DISABLE takes precedence over MADV_HUGEPAGE. > 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?
