On Tue, Dec 14, 2021 at 3:57 AM Marc Zyngier <maz@xxxxxxxxxx> wrote: > > On Tue, 14 Dec 2021 06:24:38 +0000, > Reiji Watanabe <reijiw@xxxxxxxxxx> wrote: > > > > Hi Alex, > > > > On Mon, Dec 13, 2021 at 3:14 AM Alexandru Elisei > > <alexandru.elisei@xxxxxxx> wrote: > > > > > > Also, as VCPUs get migrated from one physical CPU to the other, the > > > semantics of the microarchitectural events change, even if the event ID is > > > the same. > > > > Yes, I understand. As mentioned, this can work only when the > > CPU affinity is set for vCPU threads appropriately (, which could > > be done even without changing userspace). > > Implicit bindings to random PMUs based on the scheduling seems a > pretty fragile API to me, Yes, I understand that. I was just looking into the possibility of improving the default behavior in some way rather than keeping the unpredictable default behavior. > and presents no real incentive for userspace > to start doing the right thing. I see... It makes sense. I didn't think about that aspect. > I'd prefer not counting events at all when on the wrong CPU (for some > definition of 'wrong'), rather than accumulating unrelated events. > Both are admittedly wrong, but between two evils, I'd rather stick > with the one I know (and that doesn't require any change)... > > Alex's series brings a way to solve this by allowing userspace to pick > a PMU and make sure userspace is aware of the consequences. It puts > userspace in charge, and doesn't leave space for ambiguous behaviours. > > I definitely find value in this approach. Yes, I agree with that. It wasn't meant to replace Alex's approach. It was only about the default behavior (i.e. when userspace does not specify a PMUID with the new API). Anyway, thank you so much for sharing your thoughts on it ! Regards, Reiji _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
