On 2016/10/13 16:08, js1...@gmail.com wrote:
> From: Joonsoo Kim <iamjoonsoo....@lge.com>
>
> Currently, freeing page can stay longer in the buddy list if next higher
> order page is in the buddy list in order to help coalescence. However,
> it doesn't work for the simplest sequential free case. For example, think
> about the situation that 8 consecutive pages are freed in sequential
> order.
>
> page 0: attached at the head of order 0 list
> page 1: merged with page 0, attached at the head of order 1 list
> page 2: attached at the tail of order 0 list
> page 3: merged with page 2 and then merged with page 0, attached at
> the head of order 2 list
> page 4: attached at the head of order 0 list
> page 5: merged with page 4, attached at the tail of order 1 list
> page 6: attached at the tail of order 0 list
> page 7: merged with page 6 and then merged with page 4. Lastly, merged
> with page 0 and we get order 3 freepage.
>
> With excluding page 0 case, there are three cases that freeing page is
> attached at the head of buddy list in this example and if just one
> corresponding ordered allocation request comes at that moment, this page
> in being a high order page will be allocated and we would fail to make
> order-3 freepage.
>
> Allocation usually happens in sequential order and free also does. So, it
> would be important to detect such a situation and to give some chance
> to be coalesced.
>
> I think that simple and effective heuristic about this case is just
> attaching freeing page at the tail of the buddy list unconditionally.
> If freeing isn't merged during one rotation, it would be actual
> fragmentation and we don't need to care about it for coalescence.
>
Hi Joonsoo,
I find another two places to reduce fragmentation.
1)
__rmqueue_fallback
steal_suitable_fallback
move_freepages_block
move_freepages
list_move
If we steal some free pages, we will add these page at the head of
start_migratetype list,
this will cause more fixed migratetype, because this pages will be allocated
more easily.
So how about use list_move_tail instead of list_move?
2)
__rmqueue_fallback
expand
list_add
How about use list_add_tail instead of list_add? If add the tail, then the rest
of pages
will be hard to be allocated and we can merge them again as soon as the page
freed.
Thanks,
Xishi Qiu
