Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752120AbbFZKXE (ORCPT ); Fri, 26 Jun 2015 06:23:04 -0400 Received: from cantor2.suse.de ([195.135.220.15]:48547 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752140AbbFZKWq (ORCPT ); Fri, 26 Jun 2015 06:22:46 -0400 Date: Fri, 26 Jun 2015 11:22:41 +0100 From: Mel Gorman To: Joonsoo Kim Cc: Joonsoo Kim , Andrew Morton , LKML , Linux Memory Management List , Vlastimil Babka , Rik van Riel , David Rientjes , Minchan Kim Subject: Re: [RFC PATCH 00/10] redesign compaction algorithm Message-ID: <20150626102241.GH26927@suse.de> References: <1435193121-25880-1-git-send-email-iamjoonsoo.kim@lge.com> <20150625110314.GJ11809@suse.de> <20150625172550.GA26927@suse.de> <20150625184135.GB26927@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2966 Lines: 59 On Fri, Jun 26, 2015 at 11:07:47AM +0900, Joonsoo Kim wrote: > >> > The long-term success rate of fragmentation avoidance depends on > >> > minimsing the number of UNMOVABLE allocation requests that use a > >> > pageblock belonging to another migratetype. Once such a fallback occurs, > >> > that pageblock potentially can never be used for a THP allocation again. > >> > > >> > Lets say there is an unmovable pageblock with 500 free pages in it. If > >> > the freepage scanner uses that pageblock and allocates all 500 free > >> > pages then the next unmovable allocation request needs a new pageblock. > >> > If one is not completely free then it will fallback to using a > >> > RECLAIMABLE or MOVABLE pageblock forever contaminating it. > >> > >> Yes, I can imagine that situation. But, as I said above, we already use > >> non-movable pageblock for migration scanner. While unmovable > >> pageblock with 500 free pages fills, some other unmovable pageblock > >> with some movable pages will be emptied. Number of freepage > >> on non-movable would be maintained so fallback doesn't happen. > >> > >> Anyway, it is better to investigate this effect. I will do it and attach > >> result on next submission. > >> > > > > Lets say we have X unmovable pageblocks and Y pageblocks overall. If the > > migration scanner takes movable pages from X then there is more space for > > unmovable allocations without having to increase X -- this is good. If > > the free scanner uses the X pageblocks as targets then they can fill. The > > next unmovable allocation then falls back to another pageblock and we > > either have X+1 unmovable pageblocks (full steal) or a mixed pageblock > > (partial steal) that cannot be used for THP. Do this enough times and > > X == Y and all THP allocations fail. > > This was similar with my understanding but different conclusion. > > As number of unmovable pageblocks, X, which is filled by movable pages > due to this compaction change increases, reclaimed/migrated out pages > from them also increase. There is no guarantee of that, it's timing sensitive and the kernel sepends more time copying data in/out of the same pageblocks which is wasteful. > And, then, further unmovable allocation request > will use this free space and eventually these pageblocks are totally filled > by unmovable allocation. Therefore, I guess, in the long-term, increasing X > is saturated and X == Y will not happen. > The whole reason we avoid migrating to unmovable blocks is because it did happen and quite quickly. Do not use unmovable blocks as migration targets. If high-order kernel allocations are required then some reclaim is necessary for compaction to work with. -- Mel Gorman SUSE Labs -- 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/