On Thu, Jun 15, 2017 at 3:22 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Thu 15-06-17 13:21:46, Dan Williams wrote: >> On Thu, Jun 15, 2017 at 1:07 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: >> > On Wed 14-06-17 12:26:46, Dan Williams wrote: >> >> On Wed, Jun 14, 2017 at 5:45 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: >> >> > On Tue 13-06-17 16:08:26, Dan Williams wrote: >> >> >> Turn the macro into a static inline and rewrite the condition checks for >> >> >> better readability in preparation for adding another condition. >> >> >> >> >> >> Cc: Jan Kara <jack@xxxxxxx> >> >> >> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> >> >> >> Reviewed-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> >> >> >> [ross: fix logic to make conversion equivalent] >> >> >> Acked-by: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx> >> >> >> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> >> >> > >> >> > This is really a nice deobfuscation! Please note this will conflict with >> >> > http://lkml.kernel.org/r/1496415802-30944-1-git-send-email-rppt@xxxxxxxxxxxxxxxxxx >> >> > >> >> > >> >> > Trivial to resolve but I thought I should give you a heads up. >> >> >> >> Hmm, I'm assuming that vma_is_dax() should override PRCTL_THP_DISABLE? >> >> ...and while we're there should vma_is_dax() also override >> >> VM_NOHUGEPAGE? This is with the assumption that the reason to turn off >> >> huge pages is to avoid mm pressure, dax exerts no such pressure. >> > >> > As the changelog of the referenced patch says another reason is to stop >> > khugepaged from interfering and collapsing smaller pages into THP. If >> > DAX mappings are subject to khugepaged then we really need to exclude >> > it. Why would you want to override user's decision to disable THP >> > anyway? I can see why the global knob should be ignored but if the >> > disable is targeted for the specific VMA or the process then we should >> > obey that, no? >> >> I don't think DAX mappings have any interaction with THP machinery >> outside of piggybacking on some of the paths in the fault handling and >> the helpers to manage huge page table entries. Since DAX disables the >> page cache, and all DAX mappings are file-backed I don't see a need >> for a user to disable THP... does anybody else? > > So let me ask differently. If the VMA is explicitly marked to not use > THP resp. the process explicitly asked to be opted out from THP why > should we make any exception for DAX? What makes DAX so special to > ignore what an user asked for? Hmm, the only case where this is a problem is in the device-dax case where it tries to guarantee a given fault granularity. In the filesystem-dax case it will fall back to 4K mappings which is expected, device-dax will just fail which is not. However, I think I can solve this just with better device-dax documentation that highlights this side-effect of disabling THP when the device is configured to support a minimum TLB size that is greater than PAGE_SIZE. -- 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>
