On Thu, Jun 07, 2018 at 09:09:10AM -0700, Stephane Eranian wrote:
> On Wed, Jun 6, 2018 at 11:22 PM Jiri Olsa wrote:
> >
> > On Wed, Jun 06, 2018 at 04:19:02PM -0700, Andi Kleen wrote:
> > > On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote:
> > > > Currently by default we try to match the
On Wed, Jun 6, 2018 at 11:22 PM Jiri Olsa wrote:
>
> On Wed, Jun 06, 2018 at 04:19:02PM -0700, Andi Kleen wrote:
> > On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote:
> > > Currently by default we try to match the user specified PMU
> > > name to all PMU units available and use them to ag
On Wed, Jun 06, 2018 at 04:19:02PM -0700, Andi Kleen wrote:
> On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote:
> > Currently by default we try to match the user specified PMU
> > name to all PMU units available and use them to aggregate
> > all matched PMUs event counts into one 'pattern'
On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote:
> Currently by default we try to match the user specified PMU
> name to all PMU units available and use them to aggregate
> all matched PMUs event counts into one 'pattern' event.
>
> While this is useful for uncore events, it screws up na
Currently by default we try to match the user specified PMU
name to all PMU units available and use them to aggregate
all matched PMUs event counts into one 'pattern' event.
While this is useful for uncore events, it screws up names
for other events, where this is not desirable, like:
Before:
#
5 matches
Mail list logo