[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190904204241.y6c335djr3bwm6xo@ca-dmjordan1.us.oracle.com>
Date: Wed, 4 Sep 2019 16:42:41 -0400
From: Daniel Jordan <daniel.m.jordan@...cle.com>
To: Florian Schmidt <florian.schmidt@...anix.com>
Cc: Jonathan Corbet <corbet@....net>,
Andrew Morton <akpm@...ux-foundation.org>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Kirill Tkhai <ktkhai@...tuozzo.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH 0/2] trace-vmscan-postprocess: fix parsing and output
On Tue, Sep 03, 2019 at 11:14:07AM +0000, Florian Schmidt wrote:
> This patch series updates trace-vmscan-postprocess.pl to work without
> throwing warnings and errors which stem from updates to several trace
> points.
Cc Yafang, who made (most of?) these updates.
> 3481c37ffa1d ("mm/vmscan: drop may_writepage and classzone_idx from
> direct reclaim begin template") removed "may_writepage" from
> mm_vmscan_direct_reclaim_begin, and 3b775998eca7
> ("include/trace/events/vmscan.h: drop zone id from kswapd tracepoints")
> removed "zid" from mm_vmscan_wakeup_kswapd. The output of
> mm_vmscan_lru_isolate and mm_vmscan_lru_shrink_active seems to never
> have matched the format of the trace point output since they were
> created, or at least for as long as I can tell. Patch 1 aligns the
> format parsing of the perl script with the current output of the trace
> points.
Thanks, patch 1 fixes the script for me for all tracepoints you touched.
> In addition, the tables that are printed by the script were not properly
> aligned any more, so patch 2 fixes the spacing.
Nit, not for Pages Scanned. With your series I get
Kswapd Kswapd Order Pages Pages Pages Pages
Instance Wakeups Re-wakeup Scanned Rclmed Sync-IO ASync-IO
kswapd0-175 1 0 253694 253691 3 129896 wake-0=1
> A side remark: parsing the trace output for mm_vmscan_lru_shrink_active
> has been in the script ever since it was created in 2010, but at no
> point the parsed output was ever used for anything. I updated the
> parsing code now, but I wonder if we could just get rid of that part...
I wonder if we shouldn't just get rid of the whole script, it's hard to
remember to keep in sync with vmscan changes and I can't think of a way to
remedy that short of having mm regression tests that run this. But your
patches are an improvement for now.
Powered by blists - more mailing lists