linux-kernel - Re: [RFC PATCH 6/6] mm, compaction: don't migrate in blocks that cannot be fully compacted in async direct compaction

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]

Message-ID: <alpine.DEB.2.02.1406041705140.22536@chino.kir.corp.google.com>
Date:	Wed, 4 Jun 2014 17:08:59 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Vlastimil Babka <vbabka@...e.cz>
cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Thelen <gthelen@...gle.com>,
	Minchan Kim <minchan@...nel.org>, Mel Gorman <mgorman@...e.de>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Christoph Lameter <cl@...ux.com>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [RFC PATCH 6/6] mm, compaction: don't migrate in blocks that
 cannot be fully compacted in async direct compaction

On Wed, 4 Jun 2014, Vlastimil Babka wrote:

> In direct compaction, we want to allocate the high-order page as soon as
> possible, so migrating from a block of pages that contains also unmigratable
> pages just adds to allocation latency.
> 

The title of the patch in the subject line should probably be reworded 
since it implies we never isolate from blocks that cannot become 
completely free and what you're really doing is skipping cc->order aligned 
pages.

> This patch therefore makes the migration scanner skip to the next cc->order
> aligned block of pages as soon as it cannot isolate a non-free page. Everything
> isolated up to that point is put back.
> 
> In this mode, the nr_isolated limit to COMPACT_CLUSTER_MAX is not observed,
> allowing the scanner to scan the whole block at once, instead of migrating
> COMPACT_CLUSTER_MAX pages and then finding an unmigratable page in the next
> call. This might however have some implications on too_many_isolated.
> 
> Also in this RFC PATCH, the "skipping mode" is tied to async migration mode,
> which is not optimal. What we most probably want is skipping in direct
> compactions, but not from kswapd and hugepaged.
> 
> In very preliminary tests, this has reduced migrate_scanned, isolations and
> migrations by about 10%, while the success rate of stress-highalloc mmtests
> actually improved a bit.
> 

Ok, so this obsoletes my patchseries that did something similar.  I hope 
you can rebase this set on top of linux-next and then propose it formally 
without the RFC tag.

We also need to discuss the scheduling heuristics, the reliance on 
need_resched(), to abort async compaction.  In testing, we actualy 
sometimes see 2-3 pageblocks scanned before terminating and thp has a very 
little chance of being allocated.  At the same time, if we try to fault 
64MB of anon memory in and each of the 32 calls to compaction are 
expensive but don't result in an order-9 page, we see very lengthy fault 
latency.

I think it would be interesting to consider doing async compaction 
deferral up to 1 << COMPACT_MAX_DEFER_SHIFT after a sysctl-configurable 
amount of memory is scanned, at least for thp, and remove the scheduling 
heuristic entirely.
--
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/