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

[Vlastimil Babka <vbabka@suse.cz>]

On 2.9.2015 10:55, Konstantin Khlebnikov wrote:
> 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)

That's exactly what happens when
/sys/kernel/mm/transparent_hugepage/defrag is set to "madvise".

> I think we'll get all benefits without losing performance.

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