Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751335AbbGWF26 (ORCPT ); Thu, 23 Jul 2015 01:28:58 -0400 Received: from LGEMRELSE7Q.lge.com ([156.147.1.151]:59617 "EHLO lgemrelse7q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750702AbbGWF2y (ORCPT ); Thu, 23 Jul 2015 01:28:54 -0400 X-Original-SENDERIP: 10.177.222.220 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Thu, 23 Jul 2015 14:33:19 +0900 From: Joonsoo Kim To: Vlastimil Babka Cc: Mel Gorman , Andrew Morton , LKML , Linux Memory Management List , Rik van Riel , David Rientjes , Minchan Kim Subject: Re: [RFC PATCH 00/10] redesign compaction algorithm Message-ID: <20150723053319.GE4449@js1304-P5Q-DELUXE> References: <1435193121-25880-1-git-send-email-iamjoonsoo.kim@lge.com> <20150625110314.GJ11809@suse.de> <20150625172550.GA26927@suse.de> <20150625184135.GB26927@suse.de> <20150626102241.GH26927@suse.de> <20150708082458.GA17015@js1304-P5Q-DELUXE> <55AE109A.4020803@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AE109A.4020803@suse.cz> 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: 4871 Lines: 112 On Tue, Jul 21, 2015 at 11:27:54AM +0200, Vlastimil Babka wrote: > On 07/08/2015 10:24 AM, Joonsoo Kim wrote: > >On Fri, Jun 26, 2015 at 11:22:41AM +0100, Mel Gorman wrote: > >>On Fri, Jun 26, 2015 at 11:07:47AM +0900, Joonsoo Kim wrote: > >> > >>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. > > > >Hello, Mel and Vlastimil. > > > >Sorry for late response. I need some time to get the number and it takes > >so long due to bugs on page owner. Before mentioning about this patchset, > >I should mention that result of my previous patchset about active > >fragmentation avoidance that you have reviewed is wrong. Incorrect result > >is caused by page owner bug and correct result shows just slight > >improvement rather than dramatical improvment. > > > >https://lkml.org/lkml/2015/4/27/92 > > Doh, glad you found the bug. > BTW I still think patch 1 of that series would make sense and it's a > code cleanup too. Patch 2 would depend on the corrected > measurements. Patch 3 also, and the active anti-fragmentation work > could be done by kcompactd if the idea of that thread floats. Yes, I don't give up those patches. :) > > >Back to our discussion, indeed, you are right. As you expected, > >fragmentation increases due to this patch. It's not much but adding > >other changes of this patchset accelerates fragmentation more so > >it's not tolerable in the end. > > > >Below is number of *non-mixed* pageblock measured by page owner > >after running modified stress-highalloc test that repeats test 3 times > >without rebooting like as Vlastimil did. > > > >pb[n] means that it is measured after n times runs of stress-highalloc > >test without rebooting. They are averaged by 3 runs. > > > > base nonmovable redesign revert-nonmovable > >pb[1]:DMA32:movable: 1359 1333 1303 1380 > >pb[1]:Normal:movable: 368 341 356 364 > > > >pb[2]:DMA32:movable: 1306 1277 1216 1322 > >pb[2]:Normal:movable: 359 345 325 349 > > > >pb[3]:DMA32:movable: 1265 1240 1179 1276 > >pb[3]:Normal:movable: 330 330 312 332 > > > >Allowing scanning on nonmovable pageblock increases fragmentation so > >non-mixed pageblock is reduced by rougly 2~3%. Whole of this patchset > >bumps this reduction up to roughly 6%. But, with reverting nonmovable > >patch, it get restored and looks better than before. > > Hm that's somewhat strange. Why is it only the *combination* of > "nonmovable" and "redesign" that makes it so bad? I guess that freepage scanner scans limited zone range in nonmovable case so bad effect is also limited. > >Nevertheless, still, I'd like to change freepage scanner's behaviour > >because there are systems that most of pageblocks are unmovable pageblock. > >In this kind of system, without this change, compaction would not > >work well as my experiment, build-frag-unmovable, showed, and essential > >high-order allocation fails. > > > >I have no idea how to overcome this situation without this kind of change. > >If you have such a idea, please let me know. > > Hm it's a tough one :/ > > >Here is similar idea to handle this situation without causing more > >fragmentation. Changes as following: > > > >1. Freepage scanner just scan only movable pageblocks. > >2. If freepage scanner doesn't find any freepage on movable pageblocks > >and whole zone range is scanned, freepage scanner start to scan on > >non-movable pageblocks. > > > >Here is the result. > > new-idea > >pb[1]:DMA32:movable: 1371 > >pb[1]:Normal:movable: 384 > > > >pb[2]:DMA32:movable: 1322 > >pb[2]:Normal:movable: 372 > > > >pb[3]:DMA32:movable: 1273 > >pb[3]:Normal:movable: 358 > > > >Result is better than revert-nonmovable case. Although I didn't attach > >the whole result, this one is better than revert one in term of success > >rate. > > > >Before starting to optimize this idea, I'd like to hear your opinion > >about this change. > > Well, it might be better than nothing. Optimization could be > remembering from the first pass which pageblock was the emptiest? > But that would make the first pass more involved, so I'm not sure. Now, I don't have any idea for it. I need more think. Thanks. -- 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/