lkml.org 
[lkml]   [2011]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: Do not stall in synchronous compaction for THP allocations
On Fri, 11 Nov 2011, Mel Gorman wrote:

> > Indeed. It seems like the behavior would better be controlled with
> > /sys/kernel/mm/transparent_hugepage/defrag which is set aside specifically
> > to control defragmentation for transparent hugepages and for that
> > synchronous compaction should certainly apply.
>
> With khugepaged in place, it's adding a tunable that is unnecessary and
> will not be used. Even if such a tuneable was created, the default
> behaviour should be "do not stall".
>

Not sure what you mean, the tunable already exists and defaults to always
if THP is turned on. I've been able to effectively control the behavior
of synchronous compaction with it in combination with extfrag_threshold,
i.e. always compact even if the fragmentation index is very small, for
workloads that really really really want hugepages at fault when such a
latency is permissable and then disable khugepaged entirely in the
background for cpu bound tasks.

The history of this boolean is somewhat disturbing: it's introduced in
77f1fe6b back on January 13 to be true after the first attempt at
compaction, then changed to be !(gfp_mask & __GFP_NO_KSWAPD) in 11bc82d6
on March 22, then changed to be true again in c6a140bf on May 24, then
proposed to be changed right back to !(gfp_mask & __GFP_NO_KSWAPD) in this
patch again. When are we going to understand that the admin needs to tell
the kernel when we'd really like to try to allocate a transparent hugepage
and when it's ok to fail?


\
 
 \ /
  Last update: 2011-11-11 11:41    [W:0.125 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site