>>> >>> I am now rethinking the decision to proceed with b) as described above. >>> >>> With the exception of MADV_REMOVE (which we may be able to change for >>> hugetlb), madvise operations operate on huge page size pages for hugetlb >>> mappings. If start address is in the middle of a hugetlb page, we essentially >>> align down to the beginning of the hugetlb page. If length lands in the >>> middle of a hugetlb page, we essentially round up. >> >> Which MADV calls would be affected? > > Not sure I understand the question. I was saying that madvise calls which > operate on hugetlb mappings today only operate on huge pages. So, this is > essentially align down starting address and align up end address. Let me clarify: If you accidentially MADV_NORMAL/MADV_RANDOM/MADV_SEQUENTIAL/MADV_WILLNEED a range that's slightly bigger/smaller than the requested one you don't actually care, because it will only slightly affect the performance of an application, if at all. MADV_COLD/MADV_PAGEOUT should be similar. I assume these don't apply to hugetlb at all. The effects of MADV_MERGEABLE/MADV_UNMERGEABLE/MADV_HUGEPAGE/MADV_NOHUGEPAGE should in theory be similar, however, there can be some user-space visible effects when you get it wrong. I assume these don't apply to hugetlb at all. However, for MADV_DONTNEED/MADV_REMOVE/MADV_DONTFORK/MADV_DOFORK/MADV_FREE/MADV_WIPEONFORK/MADV_KEEPONFORK/MADV_DONTDUMP/MADV_DODUMP/.... the application could easily detect the difference of the actual range handling. > For example consider the MADV_POPULATE calls you recently added. They will > only fault in huge pages in a hugetlb vma. On a related note: I don't see my man page updates upstream yet. And the last update upstream seems to have happened 5 months ago ... not sure why the man project seems to have stalled. https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/ -- Thanks, David / dhildenb
