Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1508808

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

Show all headers | View raw

On 2016/10/26 12:37, Joonsoo Kim wrote:

> On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote:
>> On 2016/10/13 16:08, js1304@gmail.com wrote:
>>
>>> From: Joonsoo Kim <iamjoonsoo.kim@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?
> 
> Yeah... I don't think deeply but, at a glance, it would be helpful.
> 
>>
>> 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.
> 
> I guess that it has no effect. When we do __rmqueue_fallback() and
> expand(), we don't have any freepage on this or more order. So,
> list_add or list_add_tail will show the same result.
> 

Hi Joonsoo,

Usually this list is empty, but in the following case, the list is not empty.

__rmqueue_fallback
	steal_suitable_fallback
		move_freepages_block  // move to the list of start_migratetype
	expand  // split the largest order first
		list_add  // add to the list of start_migratetype

Thanks,
Xishi Qiu

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH 0/5] Reduce fragmentation js1304@gmail.com - 2016-10-13 10:10 +0200
  [RFC PATCH 4/5] mm/page_alloc: add fixed migratetype pageblock infrastructure js1304@gmail.com - 2016-10-13 10:10 +0200
  [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list js1304@gmail.com - 2016-10-13 10:10 +0200
    Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the  tail of the buddy list Vlastimil Babka <vbabka@suse.cz> - 2016-10-13 11:30 +0200
      Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the  tail of the buddy list Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-10-14 03:10 +0200
    Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the  tail of the buddy list Xishi Qiu <qiuxishi@huawei.com> - 2016-10-17 11:30 +0200
      Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the  tail of the buddy list Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-10-26 06:40 +0200
        Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the  tail of the buddy list Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-10-26 08:00 +0200
          Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the  tail of the buddy list Xishi Qiu <qiuxishi@huawei.com> - 2016-10-26 08:10 +0200
        Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the  tail of the buddy list Xishi Qiu <qiuxishi@huawei.com> - 2016-10-26 08:00 +0200
  [RFC PATCH 3/5] mm/page_alloc: stop instantly reusing freed page js1304@gmail.com - 2016-10-13 10:10 +0200
    Re: [RFC PATCH 3/5] mm/page_alloc: stop instantly reusing freed page Vlastimil Babka <vbabka@suse.cz> - 2016-10-13 13:20 +0200
      Re: [RFC PATCH 3/5] mm/page_alloc: stop instantly reusing freed page Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-10-14 03:30 +0200

csiph-web