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

[Vlastimil Babka <vbabka@suse.cz>]

On 09/10/2015 06:45 PM, Andrea Arcangeli wrote:
>> >Mysql (tokudb)
>> >https://dzone.com/articles/why-tokudb-hates-transparent
> This seems a THP issue: unless the alternate malloc allocator starts
> using MADV_NOHUGEPAGE, its memory loss would become extreme with the
> split_huge_page pending changes from Kirill. There's little the kernel
> can do about this, in fact Kirill's latest changes goes in the very
> opposite direction of what's needed to reduce the memory footprint for
> this MADV_DONTNEED 4kb case.
>
> With current code however the best you can do is:
>
> echo 0 >/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none
>
> That will guarantee that khugepaged never increases the memory
> footprint after a MADV_DONTNEED done by the alternate malloc
> allocator. Just that will definitely stop to help with the
> split_huge_page pending changes. You could consider testing that but
> if the split_huge_page pending changes are merged, this tuning shall
> disappear.

I don't think it's that pessimistic after Kirill's patchset? 
MADV_DONTNEED should still result in unmaps, which results in 
split_huge_pmd. Then the THP is put in a shrinker list and will be fully 
split in response to memory pressure, see:

  [PATCHv10 34/36] thp: introduce deferred_split_huge_page()


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