[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160613051214.GA491@swordfish>
Date: Mon, 13 Jun 2016 14:12:14 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Minchan Kim <minchan@...nel.org>,
Ganesh Mahendran <opensource.ganesh@...il.com>
Cc: Linux-MM <linux-mm@...ck.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Nitin Gupta <ngupta@...are.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
rostedt@...dmis.org, mingo@...hat.com
Subject: Re: [PATCH] mm/zsmalloc: add trace events for zs_compact
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
Powered by blists - more mailing lists