linux-kernel - Re: [RFC] mm: show deferred_compaction state in page alloc fail

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: <5422E1B8.9000100@suse.cz>
Date:	Wed, 24 Sep 2014 17:22:32 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Minchan Kim <minchan@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Mel Gorman <mgorman@...e.de>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [RFC] mm: show deferred_compaction state in page alloc fail

On 08/26/2014 09:30 AM, Minchan Kim wrote:
> Recently, I saw several reports that high order allocation failed
> although there were many freeable pages but it's hard to reproduce
> so asking them to reproduce the problem several time is really painful.
>
> A culprit I doubt is compaction deferring logic which prevent
> compaction for a while so high order allocation could be fail.

Could be that, but also the non-determinism of watermark checking, where 
compaction thinks allocation should succeed, but in the end it won't.

> It would be more clear if we can see the stat which can show
> current zone's compaction deferred state when allocatil fail.
>
> It's a RFC and never test it. I just get an idea with
> handling another strange high order allocation fail.
> Any comments are welcome.

It's quite large patch. Maybe it could be much simpler if you did not 
print just true/false but:

1) true/false based on zone->compact_considered < defer_limit, ignoring
    zone->compact_order_failed

2) zone->compact_order_failed value itself

Then you wouldn't need to pass the allocation order around like you do.
The "allocation failed" message tells you the order which was attempted, 
and then it's easy for the user to compare with the reported
zone->compact_order_failed and decide if the defer status actually 
applies or not.


--
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/