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:   Fri, 19 Jan 2018 09:34:50 -0800
From:   Stephane Eranian <eranian@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "Liang, Kan" <kan.liang@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "acme@...nel.org" <acme@...nel.org>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>
Subject: Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for
 free running counters

On Fri, Jan 19, 2018 at 9:19 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Fri, Jan 19, 2018 at 03:15:00PM +0000, Liang, Kan wrote:
> > >
> > > On Thu, Jan 18, 2018 at 05:43:10PM +0000, Liang, Kan wrote:
> > > > In the uncore document, there is no event-code assigned to free running
> > > counters.
> > > > Some events need to be defined to indicate the free running counters.
> > > > The events are encoded as event-code + umask-code.
> > > >
> > > > The event-code for all free running counters is 0xff, which is the
> > > > same as the fixed counters.
> > >
> > > Is it possible to count the same things using the generic counters?
> > >
> >
> > Yes, there are events for generic counters to count bandwidth and
> > utilization.
> >
> > The reasons of introducing free running counters are
> > - To provide highly valuable information (bandwidth and utilization)
> >    which most of the customers are interested in
> > - To save on the precious generic counters
>
> _IF_ the exact same counters are available on the GPs then we must use the
> same event code for them and use event scheduling to place them on
> fixed/free-running counters when possible.
>
> That's what we do for the CPU PMU's fixed counters too.
>
> Don't invent magic event codes just because.

I agree with Peter here. The scheduling algorithm should take care of this.
There is only one case in the core PMU where we had to invent an event code.
That was for UNHALTED_REFERENCE_CYCLES which could only be measured
on a fixed counters. But for the other two, the scheduling code takes
care of them
taking into consideration filter bits.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ