Re: [PATCH] mm/zsmalloc: add trace events for zs_compact

[Sergey Senozhatsky]

Hello,

On (06/13/16 13:42), Minchan Kim wrote:
[..]
> > compacted(total 0) */
> >  2) # 1351.241 us |  }
> > ------
> > => 1351.241 us used
> > 
> > And it seems the overhead of function_graph is bigger than trace event.
> > 
> > bash-3682  [002] ....  1439.180646: zsmalloc_compact_start: pool zram0
> > bash-3682  [002] ....  1439.180659: zsmalloc_compact_end: pool zram0:
> > 0 pages compacted(total 0)
> > => 13 us > 1351.241 us
> 
> You could use set_ftrace_filter to cut out.
> 
> To introduce new event trace to get a elasped time, it's pointless,
> I think.
> 
> It should have more like pool name you mentioned.
> Like saying other thread, It would be better to show
> [pool name, compact size_class,
> the number of object moved, the number of freed page], IMO.

just my 5 cents:

some parts (of the info above) are already available: zram<ID> maps to
pool<ID> name, which maps to a sysfs file name, that can contain the rest.
I'm just trying to understand what kind of optimizations we are talking
about here and how would timings help... compaction can spin on class
lock, for example, if the device in question is busy, etc. etc. on the
other hand we have a per-class info in zsmalloc pool stats output, so
why not extend it instead of introducing a new debugging interface?

	-ss