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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>