linux-kernel - Re: [PATCH RFC 00/10] counter read during perf sampling

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]

Message-ID: <20150927195700.GD24007@krava.redhat.com>
Date:	Sun, 27 Sep 2015 21:57:00 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	"Liang, Kan" <kan.liang@...el.com>
Cc:	"acme@...nel.org" <acme@...nel.org>,
	"jolsa@...nel.org" <jolsa@...nel.org>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"namhyung@...nel.org" <namhyung@...nel.org>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC 00/10] counter read during perf sampling

On Fri, Sep 25, 2015 at 02:57:14PM +0000, Liang, Kan wrote:

SNIP

> > >
> > > Yes, the way to store the data from perf stat is better than pure
> > > script way. I guess your patch "perf stat record" can do that, right?
> > >
> > > If so, how should we run perf record and stat in parallel? By scripts
> > > or modify perf record/stat?
> > >
> > > Also, we need an option in perf report to merge the perf.data-s. Right?
> > 
> > either that or extra step with 'perf data merge' or somthing like that
> >
> 
> Any update about "perf stat record" patch set? That will help a lot, if

I'll try to post new version this week

> we finally choose the 'perf data merge' way. Right?  

I think we could do both ways.. let user choose whatever is more convenient

SNIP

> > 
> > the way I see it you implemented 'perf stat' logic within record command
> > you create counter (non sampling) and read it via read syscall
> > 
> > I think it's good idea, but I think we should follow the way we do in perf
> > stat command and reuse the interface (and code)
> > 
> > like having the 'stat' keyword separating the non-sampling config:
> > 
> >   $ perf record -e cycles stat -e 'uncore_imc_1/cas_count_read/' -I 10000 -
> >  ./tchain_edit
> >
> 
> Another thing is that there is limitation for --interval-print in perf stat.
> The interval must >= 100ms. However, we need the interval >=10ms.
> 
> Any idea about where 100ms is from? Print limit?  

I don't recall any reason for this limitation, IMO it was just convenient
to have higher unit because lower wasn't needed.. so I think we can change
it do 10ms

SNIP

> > 
> > hum, how the --counter-read-interval data displayed then? it's not single
> > number right?
> >
> No matter which way we choose, I think the output should be similar.
> 
> As my original design, perf only output every --counter-read-interval data
> in perf report -D.
> For tui and stdio, it only output the aggregate number. So, yes, single number.
> 
> I think it should be enough. In tui/stdio, perf gives user a roughly image by
> the total number during the whole sampling process. If they want details,
> they can check by report -D.
> Considering the interval is only 10ms, if perf output everything in tui/stdio,
> the output is too huge.

what is the reason to read the counter multiple times if you display only
single number at the end? overflow issues?

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/