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]

Date:	Fri, 11 Nov 2011 15:21:00 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Mel Gorman <mgorman@...e.de>,
	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>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: Do not stall in synchronous compaction for THP
 allocations

On Fri, Nov 11, 2011 at 02:39:10AM -0800, David Rientjes wrote:
> 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?

Sorry for the confusion but it was reverted by mistake. Mel fixed a
compaction bug that caused stalls of several minutes to
people. compaction was overflowing into the next zone by mistake
without adjusting its tracking parameters. So it wasn't clear anymore
if sync compaction was really a problem or not. So I reverted it to be
sure. And well now we're sure :). Without USB or pathologically slow
I/O apparently it's not a noticeable issue.

So having sync compaction off by default sounds good to me.

We can still add a tunable to force sync compaction in case anybody
needs.

Another topic is if slub and stuff also wants sync compaction off by
default when they allocate with large order so triggering compaction.
--
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/