On 12/14/17 9:55 PM, Anshuman Khandual wrote: > On 12/15/2017 06:58 AM, Nitin Gupta wrote: >> Currently, if the THP enabled policy is "always", or the mode >> is "madvise" and a region is marked as MADV_HUGEPAGE, a hugepage >> is allocated on a page fault if the pud or pmd is empty. This >> yields the best VA translation performance, but increases memory >> consumption if some small page ranges within the huge page are >> never accessed. > > Right, thats as per design. > >> >> An alternate behavior for such page faults is to install a >> hugepage only when a region is actually found to be (almost) >> fully mapped and active. This is a compromise between > > That is the async method by analyzing page table segment for > the process by khugepaged and evaluate if a huge page can be > installed replacing the existing pages. > >> translation performance and memory consumption. Currently there >> is no way for an application to choose this compromise for the >> page fault conditions above. > > Cant we mark the THP enablement mode as "madvise", then switch > between MADV_HUGEPAGE/MADV_NOHUGEPAGE to implement this ? > Asking applications to issue MADV_HUGEPAGE/NOHUGEPAGE would make THP much less 'automatic'. With such a scheme applications would have to track mapping and active status of each hugepage region and manually issue MADV_HUGEPAGE again to let khugepaged back it with a hugepage. Compare above with the approach used by this patch: MADV_DONTNEED is taken as a hint that application still wants transparent hugepages but wants to be more conservative with memory usage. khugepaged is still free to collapse pages as it sees fit without explicit HUGEPAGE/NOHUGEPAGE madvise hints. >> >> With this change, when an application issues MADV_DONTNEED on a >> memory region, the region is marked as "space-efficient". For > > Isn't it that MADV_DONTNEED should be used for a region where > there are already pages faulted in and page table populated ? > Are you suggesting that MADV_DONTNEED should be called upon > a region just after creation to control it's fault behavior ? > Thats not what MADV_DONTNEED was meant to be. > No, I'm not suggesting MADV_DONTNEED be called on empty region. The patch just uses these calls, whenever they are made, as a hint to be more conservative with memory usage for that vma. >> such regions, a hugepage is not immediately allocated on first >> write. Instead, it is left to the khugepaged thread to do >> delayed hugepage promotion depending on whether the region is >> actually mapped and active. When application issues >> MADV_HUGEPAGE, the region is marked again as non-space-efficient >> wherein hugepage is allocated on first touch > > But MADV_HUGEPAGE/MADV_NOHUGEPAGE combination should do the trick > as well. > Thanks, Nitin -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
