[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <36624B5E-12F3-437D-90B6-E3197D31A0F3@gmail.com>
Date: Sun, 7 Aug 2016 18:02:41 +0530
From: Janani Ravichandran <janani.rvchndrn@...il.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Janani Ravichandran <janani.rvchndrn@...il.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org, riel@...riel.com,
akpm@...ux-foundation.org, hannes@...pxchg.org,
vdavydov@...tuozzo.com, mhocko@...e.com,
mgorman@...hsingularity.net, kirill.shutemov@...ux.intel.com,
bywxiaobai@....com, rostedt@...dmis.org
Subject: Re: [PATCH 2/2] mm: compaction.c: Add/Modify direct compaction tracepoints
> On Aug 1, 2016, at 6:55 PM, Vlastimil Babka <vbabka@...e.cz> wrote:
>
>
> Yea, this tracepoint has been odd in not printing node/zone in a friendly way (it's possible to determine it from zone_start/zone_end though, so this is good in general. But instead of printing nid and zid like this, it would be nice to unify the output with the other tracepoints, e.g.:
>
> DECLARE_EVENT_CLASS(mm_compaction_suitable_template,
> [...]
> TP_printk("node=%d zone=%-8s order=%d ret=%s",
> __entry->nid,
> __print_symbolic(__entry->idx, ZONE_TYPE),
Sure, I’ll do that in v2. Thanks!
Also, I guess I should have mentioned that the tracepoint added
at the end of the compaction code wasn’t just for deriving latency information.
rc and *contended would give us the result of the compaction attempted,
which I thought would be useful.
I get that begin/end tracepoints aren’t required here, but how about having
trace_mm_compaction_try_to_compact_pages moved to the end to
include compaction status?
Janani.
>
> Thanks,
> Vlastimil
Powered by blists - more mailing lists