From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751949AbcGRJM7 (ORCPT ); Mon, 18 Jul 2016 05:12:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:55507 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751456AbcGRJM5 (ORCPT ); Mon, 18 Jul 2016 05:12:57 -0400 Subject: Re: [PATCH v3 09/17] mm, compaction: make whole_zone flag ignore cached scanner positions To: Joonsoo Kim References: <20160624095437.16385-1-vbabka@suse.cz> <20160624095437.16385-10-vbabka@suse.cz> <20160706050939.GD23627@js1304-P5Q-DELUXE> Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Mel Gorman , David Rientjes , Rik van Riel From: Vlastimil Babka Message-ID: <1c0e2da2-115e-d676-cfec-e572270789ca@suse.cz> Date: Mon, 18 Jul 2016 11:12:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160706050939.GD23627@js1304-P5Q-DELUXE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/06/2016 07:09 AM, Joonsoo Kim wrote: > On Fri, Jun 24, 2016 at 11:54:29AM +0200, Vlastimil Babka wrote: >> A recent patch has added whole_zone flag that compaction sets when scanning >> starts from the zone boundary, in order to report that zone has been fully >> scanned in one attempt. For allocations that want to try really hard or cannot >> fail, we will want to introduce a mode where scanning whole zone is guaranteed >> regardless of the cached positions. >> >> This patch reuses the whole_zone flag in a way that if it's already passed true >> to compaction, the cached scanner positions are ignored. Employing this flag > > Okay. But, please don't reset cached scanner position even if whole_zone > flag is set. Just set cc->migrate_pfn and free_pfn, appropriately. With Won't that result in confusion on cached position updates during compaction where it checks the previous cached position? I wonder what kinds of corner cases it can bring... > your following patches, whole_zone could be set without any compaction > try I don't understand what you mean here? Even after whole series, whole_zone is only checked, and positions thus reset, after passing the compaction_suitable() call from compact_zone(). So at that point we can say that compaction is being actually tried and it's not a drive-by reset? Thanks