Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint
From: Minchan Kim
Date: Thu Dec 29 2016 - 20:56:38 EST
On Thu, Dec 29, 2016 at 08:56:49AM +0100, Michal Hocko wrote:
> On Thu 29-12-16 15:02:04, Minchan Kim wrote:
> > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote:
> > > From: Michal Hocko <mhocko@xxxxxxxx>
> > >
> > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate
> > > from is file or anonymous but we do not know which LRU this is. It is
> > > useful to know whether the list is file or anonymous as well. Change
> > > the tracepoint to show symbolic names of the lru rather.
> > >
> > > Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>
> > Not exactly same with this but idea is almost same.
> > I used almost same tracepoint to investigate agging(i.e., deactivating) problem
> > in 32b kernel with node-lru.
> > It was enough. Namely, I didn't need tracepoint in shrink_active_list like your
> > first patch.
> > Your first patch is more straightforwad and information. But as you introduced
> > this patch, I want to ask in here.
> > Isn't it enough with this patch without your first one to find a such problem?
> I assume this should be a reply to
> http://lkml.kernel.org/r/20161228153032.10821-8-mhocko@xxxxxxxxxx, right?
I don't know my browser says "No such Message-ID known"
> And you are right that for the particular problem it was enough to have
> a tracepoint inside inactive_list_is_low and shrink_active_list one
> wasn't really needed. On the other hand aging issues are really hard to
What kinds of aging issue? What's the problem? How such tracepoint can help?
> debug as well and so I think that both are useful. The first one tell us
> _why_ we do aging while the later _how_ we do that.
Solve reported problem first you already knew. It would be no doubt
to merge and then send other patches about "it might be useful" with