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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>