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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux