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.
WARNING: multiple messages have this Message-ID (diff)
From: jan.glauber@caviumnetworks.com (Jan Glauber) To: linux-arm-kernel@lists.infradead.org Subject: [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: 50+ 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 ` Jan Glauber 2016-03-09 16:21 ` [PATCH v2 1/5] arm64/perf: Basic uncore counter support for Cavium ThunderX Jan Glauber 2016-03-09 16:21 ` Jan Glauber 2016-04-19 15:06 ` Mark Rutland 2016-04-19 15:06 ` Mark Rutland 2016-04-20 12:29 ` Jan Glauber [this message] 2016-04-20 12:29 ` Jan Glauber 2016-03-09 16:21 ` [PATCH v2 2/5] arm64/perf: Cavium ThunderX L2C TAD uncore support Jan Glauber 2016-03-09 16:21 ` Jan Glauber 2016-04-19 15:43 ` Mark Rutland 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-03-09 16:21 ` Jan Glauber 2016-04-19 15:56 ` Mark Rutland 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 ` Jan Glauber 2016-03-09 16:21 ` [PATCH v2 5/5] arm64/perf: Cavium ThunderX OCX TLK " Jan Glauber 2016-03-09 16:21 ` Jan Glauber 2016-04-04 12:19 ` [PATCH v2 0/5] Cavium ThunderX uncore PMU support Jan Glauber 2016-04-04 12:19 ` Jan Glauber 2016-04-25 11:22 ` Will Deacon 2016-04-25 11:22 ` Will Deacon 2016-04-25 12:02 ` Jan Glauber 2016-04-25 12:02 ` Jan Glauber 2016-04-25 13:19 ` Will Deacon 2016-04-25 13:19 ` Will Deacon 2016-04-26 12:08 ` Jan Glauber 2016-04-26 12:08 ` Jan Glauber 2016-04-26 13:53 ` Will Deacon 2016-04-26 13:53 ` Will Deacon 2016-04-27 10:51 ` Jan Glauber 2016-04-27 10:51 ` Jan Glauber 2016-04-27 11:18 ` Mark Rutland 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 10:35 ` Jan Glauber 2016-04-19 16:03 ` Mark Rutland 2016-04-19 16:03 ` Mark Rutland 2016-06-28 10:24 ` Will Deacon 2016-06-28 10:24 ` Will Deacon 2016-06-28 14:04 ` Jan Glauber 2016-06-28 14:04 ` Jan Glauber 2016-07-04 10:11 ` Will Deacon 2016-07-04 10:11 ` Will Deacon 2016-09-16 7:55 ` Will Deacon 2016-09-16 7:55 ` Will Deacon 2016-09-16 8:39 ` Jan Glauber 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.