linux-kernel - Re: linux-next: manual merge of the akpm tree with Linus' tree

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] [day] [month] [year] [list]

Message-ID: <20120822085801.GA15058@suse.de>
Date:	Wed, 22 Aug 2012 09:58:01 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: manual merge of the akpm tree with Linus' tree

On Wed, Aug 22, 2012 at 03:59:41PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in
> mm/page_alloc.c between commit c67fe3752abe ("mm: compaction: Abort async
> compaction if locks are contended or taking too long") from Linus' tree
> and commit "mm: remove __GFP_NO_KSWAPD" from the akpm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Hi Stephen,

I think this will be a temporary problem. In the patch series that contained
"mm: compaction: Abort async compaction if locks are contended or taking
too long" there is a replacement patch for "mm: remove __GFP_NO_KSWAPD"
that handles the conflict. According to the mm-commits mailing list the
replacement patch has been picked up by Andrew but I see the old
versions in linux-next/akpm. It should get resolved the next time
Andrews tree gets pushed out.

> diff --cc mm/page_alloc.c
> index 5b3cc33,cefac39..0000000
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@@ -2436,11 -2429,10 +2435,10 @@@ rebalance
>   	/*
>   	 * If compaction is deferred for high-order allocations, it is because
>   	 * sync compaction recently failed. In this is the case and the caller
>  -	 * has requested the system not be heavily disrupted, fail the
>  -	 * allocation now instead of entering direct reclaim
>  +	 * requested a movable allocation that does not heavily disrupt the
>  +	 * system then fail the allocation instead of entering direct reclaim.
>   	 */
> - 	if ((deferred_compaction || contended_compaction) &&
> - 						(gfp_mask & __GFP_NO_KSWAPD))
>  -	if (deferred_compaction)
> ++	if (deferred_compaction || contended_compaction)
>   		goto nopage;
>   
>   	/* Try direct reclaim and then allocating */

It is not obvious at all but the correct resolution is actually the
following. Andrew should already have the right version.

@@ -2437,7 +2436,7 @@ rebalance:
 	 * system then fail the allocation instead of entering direct reclaim.
 	 */
 	if ((deferred_compaction || contended_compaction) &&
-						(gfp_mask & __GFP_NO_KSWAPD))
+	    (gfp_mask & (__GFP_MOVABLE|__GFP_REPEAT)) == __GFP_MOVABLE)
 		goto nopage;
 
 	/* Try direct reclaim and then allocating */

-- 
Mel Gorman
SUSE Labs
--
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/