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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <55EF0CCD.7000009@suse.cz>
Date:	Tue, 8 Sep 2015 18:29:01 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Mel Gorman <mgorman@...e.de>,
	David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH 3/3] mm, compaction: disginguish contended status in
 tracepoint

On 09/07/2015 07:53 AM, Joonsoo Kim wrote:
> On Thu, Aug 27, 2015 at 05:24:04PM +0200, Vlastimil Babka wrote:
>> Compaction returns prematurely with COMPACT_PARTIAL when contended or has fatal
>> signal pending. This is ok for the callers, but might be misleading in the
>> traces, as the usual reason to return COMPACT_PARTIAL is that we think the
>> allocation should succeed. This patch distinguishes the premature ending
>> condition. Further distinguishing the exact reason seems unnecessary for now.
> 
> isolate_migratepages() could return ISOLATE_ABORT and skip to call
> compact_finished(). trace_mm_compaction_end() will print
> COMPACT_PARTIAL in this case and we cannot distinguish premature
> ending condition. Is it okay?

Thanks, that could be indeed misleading. It will affect
trace_mm_compaction_end() which also prints COMPACT_PARTIAL for
COMPACT_CONTENDED case as it's already changed in compact_finished(). And
there's no compaction_finished trace event to clarify. Some cases for abort can
be inferred from trace_mm_compaction_isolate_migratepages, but not all.

Maybe I could move the post-filtering for COMPACT_CONTENDED, now done in
compact_finished() to the end of compact_zone()? That would both enhance also
trace_mm_compaction_end() and allow setting proper "ret" value for the
ISOLATE_ABORT case. The abort only happens for sched contention or
too_many_isolated(), which is basically another form of contention...

> Thanks.
> 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ