Re: [PATCH] mm: Do not stall in synchronous compaction for THP allocations

[David Rientjes <rientjes@google.com>]

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?

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>