From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757134AbZEZUrA (ORCPT ); Tue, 26 May 2009 16:47:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753584AbZEZUqy (ORCPT ); Tue, 26 May 2009 16:46:54 -0400 Received: from mail-ew0-f176.google.com ([209.85.219.176]:63592 "EHLO mail-ew0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753339AbZEZUqx (ORCPT ); Tue, 26 May 2009 16:46:53 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=b4XQHGHqVR5Hrs7Ln6ZdtR5sru/y/PLDWU1d1vWSyGovPb5cNzpY1kwpcV7t3+n/mu dyO4fWVzx5IsWrndvKiVjo0sIDG1VvnNrHMuy1lDL/kD1N8mXYDvoS6TLZ7thpa2ZA9a g1vM5xWbZWU5Rad2AkNriGeFF0PBMQRwC+Nec= Date: Tue, 26 May 2009 22:46:49 +0200 From: Frederic Weisbecker To: Li Zefan Cc: Ingo Molnar , Steven Rostedt , LKML Subject: Re: [PATCH 1/3] tracing/stat: sort in ascending order Message-ID: <20090526204647.GF5969@nowhere> References: <4A1A5AD1.3070804@cn.fujitsu.com> <20090525154229.GA7121@nowhere> <4A1B4144.9060201@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1B4144.9060201@cn.fujitsu.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 26, 2009 at 09:09:24AM +0800, Li Zefan wrote: > Frederic Weisbecker wrote: > > On Mon, May 25, 2009 at 04:46:09PM +0800, Li Zefan wrote: > >> Currently the output of trace_stat/workqueues is totally reversed: > >> > >> # cat /debug/tracing/trace_stat/workqueues > >> ... > >> 1 17 17 210 37 `-blk_unplug_work+0x0/0x57 > >> 1 3779 3779 181 11 |-cfq_kick_queue+0x0/0x2f > >> 1 3796 3796 kblockd/1:120 > >> ... > >> > >> The correct output should be: > >> > >> 1 3796 3796 kblockd/1:120 > >> 1 3779 3779 181 11 |-cfq_kick_queue+0x0/0x2f > >> 1 17 17 210 37 `-blk_unplug_work+0x0/0x57 > >> > >> It's caused by "tracing/stat: replace linked list by an rbtree for sorting" > >> (53059c9b67a62a3dc8c80204d3da42b9267ea5a0). > >> > >> Though we can simply change dummy_cmp() to return -1 instead of 1, IMO > >> it's better to always do ascending sorting in trace_stat.c, and leave each > >> stat tracer to decide whether to sort in descending or ascending order. > >> > >> [ Impact: fix the output of trace_stat/workqueue ] > >> > >> Signed-off-by: Li Zefan > > > > > > For now in stat tracing, the ascendent sorting is the most relevant. > > Especially because we always want to see the highest problems first. > > > > Yeah, I saw this. > > > -1 (or < 0) usually means lower and 1 ( > 0) is higher. > > > > I wonder what would most confuse the developers of stat tracers: > > > > - to reverse these common sort values (-1 turn into "higher") > > - keep the default ascendent sorting, which is not natural because the default > > is often descendent. > > > > I don't know. > > > > Anyone else. Do you have a preference? > > > > When I looked into this bug, I was confused why it's descending sorting, though > then I found out the answer. > > Imagine a new stat tracer wants to sort in ascending order, but it has to define > a cmp which compares in reverse order. This seems to be odd and confusing. > > But to be honest, I'm also not sure which is better, And it doesn't seem to be > a big issue. So I think I'll make concessions. Ok, so let's keep it as is and we'll see if developers complain :)