From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753500AbcFMFMS (ORCPT ); Mon, 13 Jun 2016 01:12:18 -0400 Received: from mail-pf0-f177.google.com ([209.85.192.177]:35793 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750715AbcFMFMQ (ORCPT ); Mon, 13 Jun 2016 01:12:16 -0400 Date: Mon, 13 Jun 2016 14:12:14 +0900 From: Sergey Senozhatsky To: Minchan Kim , Ganesh Mahendran Cc: Linux-MM , linux-kernel , Andrew Morton , Nitin Gupta , Sergey Senozhatsky , rostedt@goodmis.org, mingo@redhat.com Subject: Re: [PATCH] mm/zsmalloc: add trace events for zs_compact Message-ID: <20160613051214.GA491@swordfish> References: <1465289804-4913-1-git-send-email-opensource.ganesh@gmail.com> <20160608001625.GB27258@bbox> <20160608051352.GA28155@bbox> <20160613044237.GC23754@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160613044237.GC23754@bbox> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 maps to pool 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