lkml.org 
[lkml]   [2016]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2016-10-05 15:38    [W:1.507 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site