From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/5] arm64/perf: Basic uncore counter support for Cavium ThunderX
Date: Wed, 20 Apr 2016 14:29:03 +0200 [thread overview]
Message-ID: <20160420122903.GA3352@hardcore> (raw)
In-Reply-To: <20160419150607.GB20991@leverpostej>
On Tue, Apr 19, 2016 at 04:06:08PM +0100, Mark Rutland wrote:
> On Wed, Mar 09, 2016 at 05:21:03PM +0100, Jan Glauber wrote:
> > Provide "uncore" facilities for different non-CPU performance
> > counter units. Based on Intel/AMD uncore pmu support.
> >
> > The uncore drivers cover quite different functionality including
> > L2 Cache, memory controllers and interconnects.
> >
> > The uncore PMUs can be found under /sys/bus/event_source/devices.
> > All counters are exported via sysfs in the corresponding events
> > files under the PMU directory so the perf tool can list the event names.
> >
> > There are some points that are special in this implementation:
> >
> > 1) The PMU detection relies on PCI device detection. If a
> > matching PCI device is found the PMU is created. The code can deal
> > with multiple units of the same type, e.g. more than one memory
> > controller.
> > Note: There is also a CPUID check to determine the CPU variant,
> > this is needed to support different hardware versions that use
> > the same PCI IDs.
> >
> > 2) Counters are summarized across different units of the same type
> > on one NUMA node.
> > For instance L2C TAD 0..7 are presented as a single counter
> > (adding the values from TAD 0 to 7). Although losing the ability
> > to read a single value the merged values are easier to use.
>
> Merging within a NUMA node, but no further seems a little arbitrary.
>
> > 3) NUMA support. The device node id is used to group devices by node
> > so counters on one node can be merged. The NUMA node can be selected
> > via a new sysfs node attribute.
> > Without NUMA support all devices will be on node 0.
>
> It doesn't seem great that this depends on kernel configuration (which
> is independent of HW configuration). It seems confusing for the user,
> and fragile.
>
> Do we not have access to another way of grouping cores (e.g. a socket
> ID), that's independent of kernel configuration? That seems to be how
> the x86 uncore PMUs are handled.
I'm not sure how relevant the use case of a multi-node system without
CONFIG_NUMA is, but maybe we can get the socket ID from the
multiprocessor affinity register (MPIDR_EL1)? The AFF2 part (bits 23:16)
should contain the socket number on ThunderX.
Would that be better?
thanks,
Jan
> If we don't have that information, it really feels like we need
> additional info from FW (which would also solve the CPUID issue with
> point 1), or this is likely to be very fragile.
next prev parent reply other threads:[~2016-04-20 12:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 16:21 [PATCH v2 0/5] Cavium ThunderX uncore PMU support Jan Glauber
2016-03-09 16:21 ` [PATCH v2 1/5] arm64/perf: Basic uncore counter support for Cavium ThunderX Jan Glauber
2016-04-19 15:06 ` Mark Rutland
2016-04-20 12:29 ` Jan Glauber [this message]
2016-03-09 16:21 ` [PATCH v2 2/5] arm64/perf: Cavium ThunderX L2C TAD uncore support Jan Glauber
2016-04-19 15:43 ` Mark Rutland
2016-03-09 16:21 ` [PATCH v2 3/5] arm64/perf: Cavium ThunderX L2C CBC " Jan Glauber
2016-04-19 15:56 ` Mark Rutland
2016-03-09 16:21 ` [PATCH v2 4/5] arm64/perf: Cavium ThunderX LMC " Jan Glauber
2016-03-09 16:21 ` [PATCH v2 5/5] arm64/perf: Cavium ThunderX OCX TLK " Jan Glauber
2016-04-04 12:19 ` [PATCH v2 0/5] Cavium ThunderX uncore PMU support Jan Glauber
2016-04-25 11:22 ` Will Deacon
2016-04-25 12:02 ` Jan Glauber
2016-04-25 13:19 ` Will Deacon
2016-04-26 12:08 ` Jan Glauber
2016-04-26 13:53 ` Will Deacon
2016-04-27 10:51 ` Jan Glauber
2016-04-27 11:18 ` Mark Rutland
[not found] ` <CAEiAFz3eCsX3VoNus_Rq+En5zuB8fAxNCbC3ktw2NqLKwC=_kA@mail.gmail.com>
2016-04-19 10:35 ` Jan Glauber
2016-04-19 16:03 ` Mark Rutland
2016-06-28 10:24 ` Will Deacon
2016-06-28 14:04 ` Jan Glauber
2016-07-04 10:11 ` Will Deacon
2016-09-16 7:55 ` Will Deacon
2016-09-16 8:39 ` Jan Glauber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160420122903.GA3352@hardcore \
--to=jan.glauber@caviumnetworks.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).