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

From	Joonsoo Kim <js1304@gmail.com>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH 00/10] redesign compaction algorithm
Date	2015-06-26 04:20 +0200
Message-ID	<pFrpg-1YQ-17@gated-at.bofh.it> (permalink)
References	(1 earlier) <pFdcC-6Xf-7@gated-at.bofh.it> <pFiYG-6KG-25@gated-at.bofh.it> <pFj8m-6VM-13@gated-at.bofh.it> <pFjUJ-85O-3@gated-at.bofh.it> <pFkxt-nq-21@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

2015-06-26 3:56 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>:
> On 25.6.2015 20:14, Joonsoo Kim wrote:
>>> The long-term success rate of fragmentation avoidance depends on
>>> > minimsing the number of UNMOVABLE allocation requests that use a
>>> > pageblock belonging to another migratetype. Once such a fallback occurs,
>>> > that pageblock potentially can never be used for a THP allocation again.
>>> >
>>> > Lets say there is an unmovable pageblock with 500 free pages in it. If
>>> > the freepage scanner uses that pageblock and allocates all 500 free
>>> > pages then the next unmovable allocation request needs a new pageblock.
>>> > If one is not completely free then it will fallback to using a
>>> > RECLAIMABLE or MOVABLE pageblock forever contaminating it.
>> Yes, I can imagine that situation. But, as I said above, we already use
>> non-movable pageblock for migration scanner. While unmovable
>> pageblock with 500 free pages fills, some other unmovable pageblock
>> with some movable pages will be emptied. Number of freepage
>> on non-movable would be maintained so fallback doesn't happen.
>
> There's nothing that guarantees that the migration scanner will be emptying
> unmovable pageblock, or am I missing something?

As replied to Mel's comment, as number of unmovable pageblocks, which is
filled by movable pages due to this compaction change increases,
possible candidate reclaimable/migratable pages from them also increase.
So, at some time, amount of used page by free scanner and amount of
migrated page by migration scanner would be balanced.

> Worse, those pageblocks would be
> marked to skip by the free scanner if it isolated free pages from them, so
> migration scanner would skip them.

Yes, but, next iteration will move out movable pages from that pageblock
and freed pages will be used for further unmovable allocation.
So, in the long term, this doesn't make much more fragmentation.

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/

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

Thread

[RFC PATCH 00/10] redesign compaction algorithm Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2015-06-25 02:50 +0200
  [RFC PATCH 04/10] mm/compaction: clean-up restarting condition check Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2015-06-25 02:50 +0200
  [RFC PATCH 08/10] mm/compaction: remove compaction deferring Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2015-06-25 02:50 +0200
  [RFC PATCH 03/10] mm/compaction: always update cached pfn Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2015-06-25 02:50 +0200
    Re: [RFC PATCH 03/10] mm/compaction: always update cached pfn Vlastimil Babka <vbabka@suse.cz> - 2015-06-25 11:10 +0200
  [RFC PATCH 05/10] mm/compaction: make freepage scanner scans non-movable pageblock Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2015-06-25 02:50 +0200
  [RFC PATCH 01/10] mm/compaction: update skip-bit if whole pageblock is really scanned Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2015-06-25 02:50 +0200
  Re: [RFC PATCH 00/10] redesign compaction algorithm Joonsoo Kim <js1304@gmail.com> - 2015-06-26 04:10 +0200
  Re: [RFC PATCH 00/10] redesign compaction algorithm Joonsoo Kim <js1304@gmail.com> - 2015-06-26 04:20 +0200

csiph-web