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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1111110224500.7419@chino.kir.corp.google.com>
Date:	Fri, 11 Nov 2011 02:39:10 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Mel Gorman <mgorman@...e.de>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan.kim@...il.com>, Jan Kara <jack@...e.cz>,
	Andy Isaacson <adi@...apodia.org>,
	Johannes Weiner <jweiner@...hat.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/