Date:	Thu, 23 Jul 2015 14:33:19 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Vlastimil Babka <vbabka@...e.cz>
Cc:	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Rik van Riel <riel@...hat.com>,
	David Rientjes <rientjes@...gle.com>,
	Minchan Kim <minchan@...nel.org>
Subject: Re: [RFC PATCH 00/10] redesign compaction algorithm

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists