Messages in this thread | | | Date | Mon, 22 May 2017 16:44:56 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE |
| |
On Mon, May 22, 2017 at 04:36:00PM +0300, Mike Rapoport wrote: > On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > > Currently applications can explicitly enable or disable THP for a memory > > > region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of > > > these advises is used, the region will always have > > > VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags. > > > The MADV_CLR_HUGEPAGE resets both these flags and allows managing THP in > > > the region according to system-wide settings. > > > > Seems reasonable. But could you describe an use-case when it's useful in > > real world. > > My use-case was combination of pre- and post-copy migration of containers > with CRIU. > In this case we populate a part of a memory region with data that was saved > during the pre-copy stage. Afterwards, the region is registered with > userfaultfd and we expect to get page faults for the parts of the region > that were not yet populated. However, khugepaged collapses the pages and > the page faults we would expect do not occur. > > We could have used MADV_NOHUGEPAGE before populating the region with the > pre-copy data, but then, in the end, the restored application will be resumed > with vma->vm_flags different from the ones it had when it was frozen. > > Another possibility I've considered was to register the region with > userfaultfd before populating it with data, but in that case we get the > overhead of UFFD_EVENT_PAGEFAULT + UFFDIO_{COPY,ZEROPAGE} for nothing :(
Okay. Makes sense. Feel free to use my Acked-by (with change to RESET).
-- Kirill A. Shutemov
| |