linux-kernel - Re: [PATCH v2 4/4] mm, compaction: direct freepage allocation for 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]

Date:	Mon, 4 Apr 2016 13:05:19 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Mel Gorman <mgorman@...hsingularity.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Joonsoo Kim <iamjoonsoo.kim@....com>,
	Rik van Riel <riel@...hat.com>,
	David Rientjes <rientjes@...gle.com>,
	Minchan Kim <minchan@...nel.org>,
	Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH v2 4/4] mm, compaction: direct freepage allocation for
 async direct compaction

On 04/04/2016 11:31 AM, Mel Gorman wrote:
> On Thu, Mar 31, 2016 at 10:50:36AM +0200, Vlastimil Babka wrote:
>> The goal of direct compaction is to quickly make a high-order page available
>> for the pending allocation. The free page scanner can add significant latency
>> when searching for migration targets, although to succeed the compaction, the
>> only important limit on the target free pages is that they must not come from
>> the same order-aligned block as the migrated pages.
>>
>
> What prevents the free pages being allocated from behind the migration
> scanner? Having compaction abort when the scanners meet misses
> compaction opportunities but it avoids the problem of Compactor A using
> pageblock X as a migration target and Compactor B using pageblock X as a
> migration source.

It's true that there's no complete protection, but parallel async 
compactions should eventually get detect contention and back off. Sync 
compaction keeps using the free scanner, so this seemed like a safe 
thing to attempt in the initial async compaction, without compromising 
success rates thanks to the followup sync compaction.