From: Michal Hocko <mhocko@kernel.org>
To: Janani Ravichandran <janani.rvchndrn@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
riel@surriel.com, akpm@linux-foundation.org,
vdavydov@virtuozzo.com, vbabka@suse.cz,
mgorman@techsingularity.net, rostedt@goodmis.org
Subject: Re: [RFC] scripts: Include postprocessing script for memory allocation tracing
Date: Mon, 12 Sep 2016 14:16:35 +0200 [thread overview]
Message-ID: <20160912121635.GL14524@dhcp22.suse.cz> (raw)
In-Reply-To: <20160911222411.GA2854@janani-Inspiron-3521>
Hi,
I am sorry I didn't follow up on the previous submission. I find this
_really_ helpful. It is great that you could build on top of existing
tracepoints but one thing is not entirely clear to me. Without a begin
marker in __alloc_pages_nodemask we cannot really tell how long the
whole allocation took, which would be extremely useful. Or do you use
any graph tracer tricks to deduce that? There is a note in your
changelog but I cannot seem to find that in the changelog. And FWIW I
would be open to adding a tracepoint like that. It would make our life
so much easier...
On Sun 11-09-16 18:24:12, Janani Ravichandran wrote:
[...]
> allocation_postprocess.py is a script which reads from trace_pipe. It
> does the following to filter out info from tracepoints that may not
> be important:
>
> 1. Displays mm_vmscan_direct_reclaim_begin and
> mm_vmscan_direct_reclaim_end only when try_to_free_pages has
> exceeded the threshold.
> 2. Displays mm_compaction_begin and mm_compaction_end only when
> compact_zone has exceeded the threshold.
> 3. Displays mm_compaction_try_to_compat_pages only when
> try_to_compact_pages has exceeded the threshold.
> 4. Displays mm_shrink_slab_start and mm_shrink_slab_end only when
> the time elapsed between them exceeds the threshold.
> 5. Displays mm_vmscan_lru_shrink_inactive only when shrink_inactive_list
> has exceeded the threshold.
>
> When CTRL+C is pressed, the script shows the times taken by the
> shrinkers. However, currently it is not possible to differentiate among
> the
> superblock shrinkers.
>
> Sample output:
> ^Ci915_gem_shrinker_scan : total time = 8.731000 ms, max latency =
> 0.278000 ms
> ext4_es_scan : total time = 0.970000 ms, max latency = 0.129000 ms
> scan_shadow_nodes : total time = 1.150000 ms, max latency = 0.175000 ms
> super_cache_scan : total time = 8.455000 ms, max latency = 0.466000 ms
> deferred_split_scan : total time = 25.767000 ms, max latency = 25.485000
> ms
Would it be possible to group those per the context? I mean a single
allocation/per-process drop down values rather than mixing all those
values together? For example if I see that a process is talling due to
direct reclaim I would love to see what is the worst case allocation
stall and what is the most probable source of that stall. Mixing kswapd
traces would be misleading here.
Thanks!
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2016-09-12 12:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-11 22:24 [RFC] scripts: Include postprocessing script for memory allocation tracing Janani Ravichandran
2016-09-12 12:16 ` Michal Hocko [this message]
2016-09-13 18:04 ` Janani Ravichandran
2016-09-19 9:42 ` Michal Hocko
2016-09-22 15:30 ` Janani Ravichandran
2016-09-23 8:07 ` Michal Hocko
2016-10-06 12:00 ` Michal Hocko
2016-10-11 14:43 ` Janani Ravichandran
2016-10-15 23:31 ` Janani Ravichandran
2016-10-16 7:33 ` Michal Hocko
[not found] ` <CANnt6X=RpSnuxGXZfF6Qa5mJpzC8gL3wkKJi3tQMZJBZJVWF3w@mail.gmail.com>
[not found] ` <A6E7231A-54FF-4D5C-90F5-0A8C4126CFEA@gmail.com>
2016-10-18 13:13 ` Michal Hocko
2016-10-20 23:10 ` Janani Ravichandran
2016-10-21 7:08 ` Michal Hocko
2016-10-27 15:42 ` Janani Ravichandran
-- strict thread matches above, loose matches on Subject: below --
2016-08-19 11:38 Janani Ravichandran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160912121635.GL14524@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=janani.rvchndrn@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=riel@surriel.com \
--cc=rostedt@goodmis.org \
--cc=vbabka@suse.cz \
--cc=vdavydov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).