Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933286AbcDKNmb (ORCPT ); Mon, 11 Apr 2016 09:42:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:39430 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932478AbcDKNm3 (ORCPT ); Mon, 11 Apr 2016 09:42:29 -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> <570B9E50.9040000@suse.cz> <20160411132745.GH23157@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: <570BA9BD.2030404@suse.cz> Date: Mon, 11 Apr 2016 15:42:21 +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: <20160411132745.GH23157@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: 1762 Lines: 29 On 04/11/2016 03:27 PM, Michal Hocko wrote: > On Mon 11-04-16 14:53:36, Vlastimil Babka wrote: >> On 04/11/2016 02:46 PM, Michal Hocko wrote: >> >> 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. > > I am not really sure I understand. The primary intention of this patch > is to distinguish where we have scanned basically whole zones from cases > where a new scan started off previous mark and so it was just unlucky to > see only tiny bit of the zone where we would clearly give up too early. > FWIU this shouldn't be the case if we start scanning from the beginning > of the zone even if we raced on the other end of the zone because the > missed part would be negligible. Is that understanding correct? Yes, it should be less unlucky than seeing a tiny bit of the zone. Just wanted to point out that you might still not see the whole zone in one compaction attempt. E.g. async compaction is first, advances the free scanner and caches its position when it bails out due to being contended. Then direct reclaim frees some pages behind the cached position. Sync compaction attempts starts migration scanner from start_pfn, but picks up the cached free scanner pfn. The result is missing some free pages and the scanners meeting somewhat earlier than they otherwise would. Probably not critical even for OOM decisions, as that's also racy anyway.