On Tue 03-01-17 21:52:44, Michal Hocko wrote:
On Tue 03-01-17 21:47:45, Michal Hocko wrote:
> On Tue 03-01-17 18:08:58, Vlastimil Babka wrote:
> > On 12/28/2016 04:30 PM, 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>
> > > ---
> > > include/trace/events/vmscan.h | 20 ++++++++++++++------
> > > mm/vmscan.c | 2 +-
> > > 2 files changed, 15 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
> > > index 6af4dae46db2..cc0b4c456c78 100644
> > > --- a/include/trace/events/vmscan.h
> > > +++ b/include/trace/events/vmscan.h
> > > @@ -36,6 +36,14 @@
> > > (RECLAIM_WB_ASYNC) \
> > > )
> > >
> > > +#define show_lru_name(lru) \
> > > + __print_symbolic(lru, \
> > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \
> > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \
> > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \
> > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \
> > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"})
> > > +
> >
> > Does this work with external tools such as trace-cmd, i.e. does it export
> > the correct format file?
>
> How do I find out?
Well, I've just checked the format file and it says
print fmt: "isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", REC->isolate_mode, REC->classzone_idx, REC->order, REC->nr_requested, REC->nr_scanned, REC->nr_skipped, REC->nr_taken, __print_symbolic(REC->lru, {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"})
So the tool should be OK as long as it can find values for LRU_*
constants. Is this what is the problem?
OK, I got it. We need enum->value translation and all the EM stuff to do
that, right?
I will rework the patch and move the definition to the rest of the EM
family...