From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754184AbcJENiI (ORCPT ); Wed, 5 Oct 2016 09:38:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34184 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751687AbcJENiH (ORCPT ); Wed, 5 Oct 2016 09:38:07 -0400 Date: Wed, 5 Oct 2016 15:38:01 +0200 From: Jiri Olsa To: Arnaldo Carvalho de Melo Cc: Jiri Olsa , lkml , Don Zickus , Joe Mario , Ingo Molnar , Peter Zijlstra , Namhyung Kim , David Ahern , Andi Kleen Subject: Re: [PATCH 20/57] perf c2c report: Add dcacheline dimension key Message-ID: <20161005133801.GA21955@krava> References: <1474558645-19956-1-git-send-email-jolsa@kernel.org> <1474558645-19956-21-git-send-email-jolsa@kernel.org> <20161005110141.GM7143@kernel.org> <20161005124537.GB14500@krava> <20161005130929.GA19307@krava> <20161005132658.GC30363@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161005132658.GC30363@kernel.org> User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 05 Oct 2016 13:38:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 05, 2016 at 10:26:58AM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 05, 2016 at 03:09:29PM +0200, Jiri Olsa escreveu: > > On Wed, Oct 05, 2016 at 02:45:37PM +0200, Jiri Olsa wrote: > > > > SNIP > > > > > > > + > > > > > + if (he->mem_info) > > > > > + addr = cl_address(he->mem_info->daddr.addr); > > > > > + > > > > > + return snprintf(hpp->buf, hpp->size, "%*s", width, hex_str(addr)); > > > > > > > > So here you get that static buffer and then truncate it? Wouldn't the > > > > perf_hpp stuff take care of this? Can't we stop using that static buffer > > > > and this truncation at such a level? > > > > > > I think we need to cut it on this level, but I actualy might recall some > > > change you did for perf_hpp to cut this on column width later on? > > > > > > I'll check on that.. > > > > ok, so it's cut later on, but it allows only for left-side alignment > > while we use the right-side one > > > > if I leave it on perf_hpp to deal with it I end up with following output: > > (check the Cacheline column) > > Which is not _that_ bad, I guess it gets like that because we expect > kernel addresses as well (longer)? exactly.. also it's the case for other columns where you have different number lengths more often.. the right side alignment is more readable in this case jirka