On Fri, Feb 4, 2022 at 1:33 AM Ravi Bangoria <ravi.bangoria@xxxxxxx> wrote: > > > > On 03-Feb-22 11:25 PM, Jim Mattson wrote: > > On Wed, Feb 2, 2022 at 9:18 PM Ravi Bangoria <ravi.bangoria@xxxxxxx> wrote: > >> > >> Hi Jim, > >> > >> On 03-Feb-22 9:39 AM, Jim Mattson wrote: > >>> On Wed, Feb 2, 2022 at 2:52 AM Ravi Bangoria <ravi.bangoria@xxxxxxx> wrote: > >>>> > >>>> Perf counter may overcount for a list of Retire Based Events. Implement > >>>> workaround for Zen3 Family 19 Model 00-0F processors as suggested in > >>>> Revision Guide[1]: > >>>> > >>>> To count the non-FP affected PMC events correctly: > >>>> o Use Core::X86::Msr::PERF_CTL2 to count the events, and > >>>> o Program Core::X86::Msr::PERF_CTL2[43] to 1b, and > >>>> o Program Core::X86::Msr::PERF_CTL2[20] to 0b. > >>>> > >>>> Note that the specified workaround applies only to counting events and > >>>> not to sampling events. Thus sampling event will continue functioning > >>>> as is. > >>>> > >>>> Although the issue exists on all previous Zen revisions, the workaround > >>>> is different and thus not included in this patch. > >>>> > >>>> This patch needs Like's patch[2] to make it work on kvm guest. > >>> > >>> IIUC, this patch along with Like's patch actually breaks PMU > >>> virtualization for a kvm guest. > >>> > >>> Suppose I have some code which counts event 0xC2 [Retired Branch > >>> Instructions] on PMC0 and event 0xC4 [Retired Taken Branch > >>> Instructions] on PMC1. I then divide PMC1 by PMC0 to see what > >>> percentage of my branch instructions are taken. On hardware that > >>> suffers from erratum 1292, both counters may overcount, but if the > >>> inaccuracy is small, then my final result may still be fairly close to > >>> reality. > >>> > >>> With these patches, if I run that same code in a kvm guest, it looks > >>> like one of those events will be counted on PMC2 and the other won't > >>> be counted at all. So, when I calculate the percentage of branch > >>> instructions taken, I either get 0 or infinity. > >> > >> Events get multiplexed internally. See below quick test I ran inside > >> guest. My host is running with my+Like's patch and guest is running > >> with only my patch. > > > > Your guest may be multiplexing the counters. The guest I posited does not. > > It would be helpful if you can provide an example. Perf on any current Linux distro (i.e. without your fix). > > I hope that you are not saying that kvm's *thread-pinned* perf events > > are not being multiplexed at the host level, because that completely > > breaks PMU virtualization. > > IIUC, multiplexing happens inside the guest. I'm not sure that multiplexing is the answer. Extrapolation may introduce greater imprecision than the erratum. If you count something like "instructions retired" three ways: 1) Unfixed counter 2) PMC2 with the fix 3) Multiplexed on PMC2 with the fix Is (3) always more accurate than (1)? > Thanks, > Ravi
