Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932176AbcDKMxn (ORCPT ); Mon, 11 Apr 2016 08:53:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:35077 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932132AbcDKMxj (ORCPT ); Mon, 11 Apr 2016 08:53:39 -0400 Subject: Re: [PATCH 06/11] mm, compaction: distinguish between full and partial COMPACT_COMPLETE To: Michal Hocko References: <1459855533-4600-1-git-send-email-mhocko@kernel.org> <1459855533-4600-7-git-send-email-mhocko@kernel.org> <570B9432.9090600@suse.cz> <20160411124653.GG23157@dhcp22.suse.cz> Cc: Andrew Morton , Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Joonsoo Kim , Hillf Danton , linux-mm@kvack.org, LKML From: Vlastimil Babka Message-ID: <570B9E50.9040000@suse.cz> Date: Mon, 11 Apr 2016 14:53:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160411124653.GG23157@dhcp22.suse.cz> 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 Content-Length: 1711 Lines: 33 On 04/11/2016 02:46 PM, Michal Hocko wrote: >> This assumes that migrate scanner at initial position implies also free >> scanner at the initial position. That should be true, because migration >> scanner is the first to run. But getting the zone->compact_cached_*_pfn is >> racy. Worse, zone->compact_cached_migrate_pfn is array distinguishing sync >> and async compaction, so it's possible that async compaction has advanced >> both its own migrate scanner cached position, and the shared free scanner >> cached position, and then sync compaction starts migrate scanner at >> start_pfn, but free scanner has already advanced. > > OK, I see. The whole thing smelled racy but I thought it wouldn't be > such a big deal. Even if we raced then only a marginal part of the zone > wouldn't be scanned, right? Or is it possible that free_pfn would appear > in the middle of the zone because of the race? The racy part is negligible but I didn't realize the sync/async migrate scanner part until now. So yeah, free_pfn could have got to middle of zone when it was in the async mode. But that also means that the async mode recently used up all free pages in the second half of the zone. WRT free pages isolation, async mode is not trying less than sync, so it shouldn't be a considerable missed opportunity if we don't rescan the it, though. >> So you might still see a false positive COMPACT_COMPLETE, just less >> frequently and probably with much lower impact. >> But if you need to be truly reliable, check also that cc->free_pfn == >> round_down(end_pfn - 1, pageblock_nr_pages) > > I do not think we need the precise check if the race window (in the > skipped zone range) is always small. > > Thanks! >