System/uncore PMUs and unit aggregation
will.deacon at arm.com
Mon Mar 20 05:37:01 PDT 2017
On Thu, Mar 16, 2017 at 04:38:28PM +0530, Ganapatrao Kulkarni wrote:
> On Thu, Nov 17, 2016 at 11:47 PM, Will Deacon <will.deacon at arm.com> wrote:
> > We currently have support for three arm64 system PMUs in flight:
> > [Cavium ThunderX] http://firstname.lastname@example.org
> > [Hisilicon Hip0x] http://email@example.com
> > [Qualcomm L2] http://firstname.lastname@example.org
> > Each of which have to deal with multiple underlying hardware units in one
> > way or another. Mark and I recently expressed a desire to expose these
> > units to userspace as individual PMU instances, since this can allow:
> > * Fine-grained control of events from userspace, when you want to see
> > individual numbers as opposed to a summed total
> > * Potentially ease migration to new SoC revisions, where the units
> > are laid out slightly differently
> > * Easier handling of cases where the units aren't quite identical
> > however, this received pushback from all of the patch authors, so there's
> > clearly a problem with this approach. I'm hoping we can try to resolve
> > this here.
> > Speaking to Mark earlier today, we came up with the following rough rules
> > for drivers that present multiple hardware units as a single PMU:
> > 1. If the units share some part of the programming interface (e.g. control
> > registers or interrupts), then they must be handled by the same PMU.
> > Otherwise, they should be treated independently as separate PMU
> > instances.
> How are we planning to handle multi-node scenario?
> if there are X separate PMUs on single socket, are we going to list 2X PMUs on
> dual socket?
Sure, why not? Retrofitting multi-node support into a PMU driver sounds
pretty messy to me, and I don't see the downside of exposing these as
separate instances (which is what they are).
More information about the linux-arm-kernel