Re: Can we disable transparent hugepages for lack of a legitimate use case please?

[Konstantin Khlebnikov <koct9i@gmail.com>]

On Wed, Sep 2, 2015 at 1:26 AM, David Rientjes <rientjes@google.com> wrote:
> On Tue, 25 Aug 2015, Vlastimil Babka wrote:
>
>> > THP works very well when system has a lot of free memory.
>> > Probably default should be weakened to "only if we have tons of free
>> > memory".
>> > For example allocate THP pages atomically, only if buddy allocator already
>> > has huge pages. Also them could be pre-zeroed in background.
>>
>> I've been proposing series that try to move more THP allocation activity from
>> the page faults into khugepaged, but no success yet.
>>
>> Maybe we should just start with changing the default of
>> /sys/kernel/mm/transparent_hugepage/defrag to "madvise".
>
> I would need to revert this internally to avoid performance degradation, I
> believe others would report the same.

What about adding new mode "guess" -- something between always and madvise?

In this mode kernel tries to avoid performance impact for non-madvised vmas and
allocates 0-order pages if hugepages are not available right now.
(for example do allocations with GFP_NOWAIT)
I think we'll get all benefits without losing performance.

>
>> This would remove the
>> reclaim and compaction for page faults and quickly fallback to order-0 pages.
>> The compaction is already crippled enough there with the GFP_TRANSHUGE
>> specific decisions in __alloc_pages_slowpath(). I've noticed it failing
>> miserably in the transhuge-stress recently, so it seems it's not worth to try
>> at all. With changing the default we can kill those GFP_TRANSHUGE checks and
>> assume that whoever uses the madvise does actually want to try harder.
>>
>
> I think the work that is being done on moving compaction to khugepaged as
> well as periodic synchronous compaction of all memory is the way to go to
> avoid lengthy stalls during fault.
>
>> Of course that does nothing about zeroing. I don't know how huge issue is that
>> one?
>>
>
> I don't believe it is an issue that cannot be worked around in userspace
> either with MADV_NOHUGEPAGE or PR_SET_THP_DISABLE.

--
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>