Re: [PATCH v2 1/2] mm: improve readability of transparent_hugepage_enabled()

[Dan Williams <dan.j.williams@intel.com>]

On Thu, Jun 15, 2017 at 3:22 PM, Michal Hocko <mhocko@kernel.org> wrote:
> On Thu 15-06-17 13:21:46, Dan Williams wrote:
>> On Thu, Jun 15, 2017 at 1:07 AM, Michal Hocko <mhocko@kernel.org> wrote:
>> > On Wed 14-06-17 12:26:46, Dan Williams wrote:
>> >> On Wed, Jun 14, 2017 at 5:45 AM, Michal Hocko <mhocko@kernel.org> 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@suse.cz>
>> >> >> Cc: Andrew Morton <akpm@linux-foundation.org>
>> >> >> Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
>> >> >> [ross: fix logic to make conversion equivalent]
>> >> >> Acked-by: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>> >> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> >> >
>> >> > This is really a nice deobfuscation! Please note this will conflict with
>> >> > http://lkml.kernel.org/r/1496415802-30944-1-git-send-email-rppt@linux.vnet.ibm.com
>> >> >
>> >> >
>> >> > 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@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>