Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755581AbbBBOTv (ORCPT ); Mon, 2 Feb 2015 09:19:51 -0500 Received: from cantor2.suse.de ([195.135.220.15]:54982 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755466AbbBBOTt (ORCPT ); Mon, 2 Feb 2015 09:19:49 -0500 Message-ID: <54CF877D.9010609@suse.cz> Date: Mon, 02 Feb 2015 15:19:41 +0100 From: Vlastimil Babka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Zhang Yanfei , Joonsoo Kim , Andrew Morton CC: Mel Gorman , David Rientjes , Rik van Riel , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhang Yanfei , Joonsoo Kim Subject: Re: [RFC PATCH v3 3/3] mm/compaction: enhance compaction finish condition References: <1422861348-5117-1-git-send-email-iamjoonsoo.kim@lge.com> <1422861348-5117-3-git-send-email-iamjoonsoo.kim@lge.com> <54CF4F61.3070905@suse.cz> In-Reply-To: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2113 Lines: 41 On 02/02/2015 02:51 PM, Zhang Yanfei wrote: >> I've got another idea for small improvement. We should only test for fallbacks >> when migration scanner has scanned (and migrated) a whole pageblock. Should be a >> simple alignment test of cc->migrate_pfn. >> Advantages: >> - potentially less checking overhead >> - chances of stealing increase if we created more free pages for migration >> - thus less fragmentation >> The cost is a bit more time spent compacting, but it's bounded and worth it >> (especially the less fragmentation) IMHO. > > This seems to make the compaction a little compicated... I kind of Just a little bit, compared to e.g. this patch :) > don't know why there is more anti-fragmentation by using this approach. Ah so let me explain. Assume we want to allocate order-3 unmovable page and have to invoke compaction because of that. The migration scanner starts in the beginning of a movable pageblock, isolates and migrates 32 pages (COMPACT_CLUSTER_MAX) from the beginning sucessfully, and then we check in compact_finished and see that the allocation could fall back to this newly created order-5 block. So we terminate compaction and allocation takes this order-5 block, allocates order-3 and the rest remains on free list of unmovable. It will try to steal more freepages from the pageblock, but there aren't any. So we have a movable block with unmovable pages. The spare free pages are eventually depleted and we fallback to another movable pageblock... bad. With the proposed change, we would try to compact the pageblock fully. Possibly we would free at least half of it, so it would be marked as unmovable during the fallback allocation, and would be able to satisfy more unmovable allocations that wouldn't have to fallback somewhere else. I don't think that finishing the scan of a single pageblock is that big of a cost here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/