linux-kernel - Re: [RFC PATCH v3 3/3] mm/compaction: enhance compaction finish condition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 02 Feb 2015 15:19:41 +0100
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Zhang Yanfei <zhangyanfei.ok@...mail.com>,
	Joonsoo Kim <js1304@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>
CC:	Mel Gorman <mgorman@...e.de>, David Rientjes <rientjes@...gle.com>,
	Rik van Riel <riel@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Zhang Yanfei <zhangyanfei@...fujitsu.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [RFC PATCH v3 3/3] mm/compaction: enhance compaction finish condition

On 02/02/2015 02:51 PM, Zhang Yanfei wrote:
>> I've got another idea for small improvement. We should only test for fallbacks
>> when migration scanner has scanned (and migrated) a whole pageblock. Should be a
>> simple alignment test of cc->migrate_pfn.
>> Advantages:
>> - potentially less checking overhead
>> - chances of stealing increase if we created more free pages for migration
>> - thus less fragmentation
>> The cost is a bit more time spent compacting, but it's bounded and worth it
>> (especially the less fragmentation) IMHO.
> 
> This seems to make the compaction a little compicated... I kind of

Just a little bit, compared to e.g. this patch :)

> don't know why there is more anti-fragmentation by using this approach.

Ah so let me explain. Assume we want to allocate order-3 unmovable page and have
to invoke compaction because of that. The migration scanner starts in the
beginning of a movable pageblock, isolates and migrates 32 pages
(COMPACT_CLUSTER_MAX) from the beginning sucessfully, and then we check in
compact_finished and see that the allocation could fall back to this newly
created order-5 block. So we terminate compaction and allocation takes this
order-5 block, allocates order-3 and the rest remains on free list of unmovable.
It will try to steal more freepages from the pageblock, but there aren't any. So
we have a movable block with unmovable pages. The spare free pages are
eventually depleted and we fallback to another movable pageblock... bad.

With the proposed change, we would try to compact the pageblock fully. Possibly
we would free at least half of it, so it would be marked as unmovable during the
fallback allocation, and would be able to satisfy more unmovable allocations
that wouldn't have to fallback somewhere else.

I don't think that finishing the scan of a single pageblock is that big of a
cost here.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/