On Tue, Feb 23, 2016 at 11:28 AM, Andrea Arcangeli [off-list ref] wrote:

On Tue, Feb 23, 2016 at 09:38:32PM +0300, Kirill A. Shutemov wrote:

quoted

pmd_trans_unstable(pmd), otherwise looks good:

Yes sorry.

quoted

Acked-by: Kirill A. Shutemov <redacted>

Thanks for the quick ack, I just noticed or I would have added it to
the resubmit, but it can be still added to -mm.

quoted

BTW, I guess DAX would need to introduce the same infrastructure for
pmd_devmap(). Dan?

There is a i_mmap_lock_write in the truncate path that saves the day
for the pmd zapping in the truncate() case without mmap_sem (the only
case anon THP doesn't need to care about as truncate isn't possible in
the anon case), but not in the MADV_DONTNEED madvise case that runs
only with the mmap_sem for reading.

The only objective of this "infrastructure" is to add no pmd_lock()ing
overhead to the page fault, if the mapping is already established but
not huge, and we've just to walk through the pmd to reach the
pte. All because MADV_DONTNEED is running with the mmap_sem for
reading unlike munmap and other slower syscalls that are forced to
mangle the vmas and have to take the mmap_sem for writing regardless.

The question for DAX is if it should do a pmd_devmap check inside
pmd_none_or_trans_huge_or_clear_bad() after pmd_trans_huge() and get
away with a one liner, or add its own infrastructure with
pmd_devmap_unstable(). In the pmd_devmap case the problem isn't just
in __handle_mm_fault. If it could share the same infrastructure it'd
be ideal.

Yes, I see no reason why we can't/shoudn't move the pmd_devmap() check
inside pmd_none_or_trans_huge_or_clear_bad().

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>