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/
> 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/