linux-kernel - Re: [LKP] Re: [perf vendor events] 3f5f0df7bf: perf-sanity-tests.perf_all_metrics

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: <CAM9d7cic6AhJGrNF7wmyowUBpp0mPu8TdiVebL4XXcotFtLUuQ@mail.gmail.com>
Date:   Thu, 14 Apr 2022 15:58:52 -0700
From:   Namhyung Kim <namhyung@...nel.org>
To:     "Liang, Kan" <kan.liang@...ux.intel.com>
Cc:     Ian Rogers <irogers@...gle.com>, Carel Si <beibei.si@...el.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        alexandre.torgue@...s.st.com, Andi Kleen <ak@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        James Clark <james.clark@....com>,
        Jiri Olsa <jolsa@...nel.org>,
        John Garry <john.garry@...wei.com>,
        Mark Rutland <mark.rutland@....com>, mcoquelin.stm32@...il.com,
        Peter Zijlstra <peterz@...radead.org>,
        Stephane Eranian <eranian@...gle.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        lkp@...ts.01.org, kbuild test robot <lkp@...el.com>
Subject: Re: [LKP] Re: [perf vendor events] 3f5f0df7bf: perf-sanity-tests.perf_all_metrics_test.fail

Hi Kan,

On Thu, Apr 14, 2022 at 12:06 PM Liang, Kan <kan.liang@...ux.intel.com> wrote:
>
>
>
> On 4/14/2022 12:09 PM, Ian Rogers wrote:
> > ```
> > $ perf stat -e '{BR_INST_RETIRED.NEAR_CALL,BR_INST_RETIRED.NEAR_TAKEN,BR_INST_RETIRED.NOT_TAKEN,cycles,cycles}:W'
> > -a sleep 1
> >   Performance counter stats for 'system wide':
> >
> >       <not counted>      BR_INST_RETIRED.NEAR_CALL
> >                 (0.00%)
> >       <not counted>      BR_INST_RETIRED.NEAR_TAKEN
> >                  (0.00%)
> >       <not counted>      BR_INST_RETIRED.NOT_TAKEN
> >                 (0.00%)
> >       <not counted>      cycles
> >                 (0.00%)
> >       <not counted>      cycles
> >                 (0.00%)
> >
> >         1.005599088 seconds time elapsed
> >
> > Some events weren't counted. Try disabling the NMI watchdog:
> >          echo 0 > /proc/sys/kernel/nmi_watchdog
> >          perf stat ...
> >          echo 1 > /proc/sys/kernel/nmi_watchdog
> > The events in group usually have to be from the same PMU. Try
> > reorganizing the group.
> > ```
> >
> > If we add two extra cycles or the original group is smaller then it is "fixed":
> > ```
> > $ perf stat -e '{BR_INST_RETIRED.NEAR_CALL,BR_INST_RETIRED.NEAR_TAKEN,BR_INST_RETIRED.NOT_TAKEN,cycles}:W'
> > -a sleep 1
> >
> >   Performance counter stats for 'system wide':
> >
> >          20,378,789      BR_INST_RETIRED.NEAR_CALL
> >         168,420,963      BR_INST_RETIRED.NEAR_TAKEN
> >          96,330,608      BR_INST_RETIRED.NOT_TAKEN
> >       1,652,230,042      cycles
> >
> >         1.008757590 seconds time elapsed
> >
> > $ perf stat -e '{BR_INST_RETIRED.NEAR_CALL,BR_INST_RETIRED.NEAR_TAKEN,BR_INST_RETIRED.NOT_TAKEN,cycles,cycles,cycles}:W'
> > -a sleep 1
> >
> >   Performance counter stats for 'system wide':
> >
> >          37,696,638      BR_INST_RETIRED.NEAR_CALL
> >                 (66.62%)
> >         298,535,151      BR_INST_RETIRED.NEAR_TAKEN
> >                  (66.63%)
> >         297,011,663      BR_INST_RETIRED.NOT_TAKEN
> >                 (66.63%)
> >       3,155,711,474      cycles
> >                 (66.65%)
> >       3,194,919,959      cycles
> >                 (66.74%)
> >       3,126,664,102      cycles
> >                 (66.72%)
> >
> >         1.006237962 seconds time elapsed
> > ```
> >
> > So the extra cycles is needed to fix weak groups when the nmi watchdog
> > is enabled and the group is an architecture dependent size.
>
> Yes, the size of the group depends on the architecture, but perf tool
> doesn't need to know the HW details. For this case, perf tool just sends
> the request with an extra cycles event in the group and lets kernel decide.

I prefer doing this in the kernel even if it'd be incomplete.
For the NMI watchdog, is it possible to check if it's enabled
at the moment, and set the fake_cpuc->idxmsk to prevent
scheduling events in validate_group()?

Thanks,
Namhyung