linux-kernel - Re: [PATCH 20/57] perf c2c report: Add dcacheline dimension key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 5 Oct 2016 15:38:01 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Jiri Olsa <jolsa@...nel.org>, lkml <linux-kernel@...r.kernel.org>,
        Don Zickus <dzickus@...hat.com>, Joe Mario <jmario@...hat.com>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Namhyung Kim <namhyung@...nel.org>,
        David Ahern <dsahern@...il.com>,
        Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH 20/57] perf c2c report: Add dcacheline dimension key

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