Re: [RFC PATCH 00/10] redesign compaction algorithm

[Vlastimil Babka <vbabka@suse.cz>]

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.

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

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

> I think this change is essential because fail on high-order allocation
> up to PAGE_COSTLY_ORDER is functional failure and MM should guarantee
> it's success. After lumpy recliam is removed, this kind of allocation
> unavoidably rely on work of compaction. We can't prevent that movable
> pageblocks are turned into unmovable pageblock because it is highly
> workload dependant.
>
> Thanks.
>

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