linux-kernel - Re: [PATCH v2 12/18] mm, compaction: more reliably increase direct compaction priority

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] [day] [month] [year] [list]

Date:	Thu, 23 Jun 2016 16:41:53 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Mel Gorman <mgorman@...hsingularity.net>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	David Rientjes <rientjes@...gle.com>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH v2 12/18] mm, compaction: more reliably increase direct
 compaction priority

On 06/01/2016 03:51 PM, Michal Hocko wrote:
> On Tue 31-05-16 15:08:12, Vlastimil Babka wrote:
>> During reclaim/compaction loop, compaction priority can be increased by the
>> should_compact_retry() function, but the current code is not optimal. Priority
>> is only increased when compaction_failed() is true, which means that compaction
>> has scanned the whole zone. This may not happen even after multiple attempts
>> with the lower priority due to parallel activity, so we might needlessly
>> struggle on the lower priority.
>>
>> We can remove these corner cases by increasing compaction priority regardless
>> of compaction_failed(). Examining further the compaction result can be
>> postponed only after reaching the highest priority. This is a simple solution
>> and we don't need to worry about reaching the highest priority "too soon" here,
>> because hen should_compact_retry() is called it means that the system is
>> already struggling and the allocation is supposed to either try as hard as
>> possible, or it cannot fail at all. There's not much point staying at lower
>> priorities with heuristics that may result in only partial compaction.
>>
>> The only exception here is the COMPACT_SKIPPED result, which means that
>> compaction could not run at all due to being below order-0 watermarks. In that
>> case, don't increase compaction priority, and check if compaction could proceed
>> when everything reclaimable was reclaimed. Before this patch, this was tied to
>> compaction_withdrawn(), but the other results considered there are in fact only
>> possible due to low compaction priority so we can ignore them thanks to the
>> patch. Since there are no other callers of compaction_withdrawn(), remove it.
>
> I agree with the change in general. I think that keeping compaction_withdrawn
> even with a single check is better because it abstracts the fact from a
> specific constant.

OK.

> Now that I think about that some more I guess you also want to update
> compaction_retries inside should_compact_retry as well, or at least
> update it only when we have reached the lowest priority. What do you
> think?

Makes sense, especially that after your suggestion, 
should_compact_retry() is not reached as long as should_reclaim_retry() 
returnes true. So I will do that.

>> Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
>
> Other than that this makes sense
> Acked-by: Michal Hocko <mhocko@...e.com>

Thanks!