From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752457AbdBMK5A (ORCPT ); Mon, 13 Feb 2017 05:57:00 -0500 Received: from outbound-smtp04.blacknight.com ([81.17.249.35]:39292 "EHLO outbound-smtp04.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751964AbdBMK47 (ORCPT ); Mon, 13 Feb 2017 05:56:59 -0500 Date: Mon, 13 Feb 2017 10:56:56 +0000 From: Mel Gorman To: Vlastimil Babka Cc: linux-mm@kvack.org, Johannes Weiner , Joonsoo Kim , David Rientjes , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 07/10] mm, compaction: restrict async compaction to pageblocks of same migratetype Message-ID: <20170213105656.2pp5mrdhlkvh73tr@techsingularity.net> References: <20170210172343.30283-1-vbabka@suse.cz> <20170210172343.30283-8-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20170210172343.30283-8-vbabka@suse.cz> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 10, 2017 at 06:23:40PM +0100, Vlastimil Babka wrote: > The migrate scanner in async compaction is currently limited to MIGRATE_MOVABLE > pageblocks. This is a heuristic intended to reduce latency, based on the > assumption that non-MOVABLE pageblocks are unlikely to contain movable pages. > > However, with the exception of THP's, most high-order allocations are not > movable. Should the async compaction succeed, this increases the chance that > the non-MOVABLE allocations will fallback to a MOVABLE pageblock, making the > long-term fragmentation worse. > > This patch attempts to help the situation by changing async direct compaction > so that the migrate scanner only scans the pageblocks of the requested > migratetype. If it's a non-MOVABLE type and there are such pageblocks that do > contain movable pages, chances are that the allocation can succeed within one > of such pageblocks, removing the need for a fallback. If that fails, the > subsequent sync attempt will ignore this restriction. > > Signed-off-by: Vlastimil Babka Ok, I really like this idea. The thinking of async originally was to reduce latency but that was also at the time when THP allocations were stalling for long periods of time. Now that the default has changed, this idea makes a lot of sense. A few months ago I would have thought that this will increase the changes that a high-order allocation for the stack may have a higher chance of failing but with VMAP_STACK, this is much less of a concern. It would be very nice to know for this patch if the number of times the extfrag tracepoint is triggered is reduced or increased by this patch. Do you have that data? -- Mel Gorman SUSE Labs