* [PATCH 00/14] arm_pmu: ACPI support @ 2017-03-17 2:11 Itaru Kitayama 2017-03-23 10:54 ` Mark Rutland 0 siblings, 1 reply; 23+ messages in thread From: Itaru Kitayama @ 2017-03-17 2:11 UTC (permalink / raw) To: linux-arm-kernel Hi Mark, I've tried your branch on Mustang. It does boot, but perf doesn't list hardware events. Are you going to try it out on Mustang as well? In Linaro Colo, the FW is 3.06.25. Itaru ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-17 2:11 [PATCH 00/14] arm_pmu: ACPI support Itaru Kitayama @ 2017-03-23 10:54 ` Mark Rutland 2017-03-25 3:18 ` Itaru Kitayama 0 siblings, 1 reply; 23+ messages in thread From: Mark Rutland @ 2017-03-23 10:54 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 17, 2017 at 11:11:47AM +0900, Itaru Kitayama wrote: > Hi Mark, Hi, > I've tried your branch on Mustang. It does boot, but perf doesn't > list hardware events. Can you please dump the dmesg here? What exactly do you see if you run: $ perf list > Are you going to try it out on Mustang as well? In Linaro Colo, the > FW is 3.06.25. As mentioned in [1], I tried the patches on an APM Mustang platform, and PMU events worked as expected. I had a local workaround for an FW bug, but this shouldn't have affected the PMU. Thanks, Mark. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493808.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-23 10:54 ` Mark Rutland @ 2017-03-25 3:18 ` Itaru Kitayama 0 siblings, 0 replies; 23+ messages in thread From: Itaru Kitayama @ 2017-03-25 3:18 UTC (permalink / raw) To: linux-arm-kernel Hi Mark, On 2017/03/23 19:54, Mark Rutland wrote: > On Fri, Mar 17, 2017 at 11:11:47AM +0900, Itaru Kitayama wrote: >> I've tried your branch on Mustang. It does boot, but perf doesn't >> list hardware events. > > Can you please dump the dmesg here? I think this time I booted into correctly the kernel based upon your branch and got a proper set of events. > What exactly do you see if you run: > > $ perf list branch-misses [Hardware event] cache-misses [Hardware event] cache-references [Hardware event] cpu-cycles OR cycles [Hardware event] instructions [Hardware event] alignment-faults [Software event] bpf-output [Software event] context-switches OR cs [Software event] cpu-clock [Software event] cpu-migrations OR migrations [Software event] dummy [Software event] emulation-faults [Software event] major-faults [Software event] minor-faults [Software event] page-faults OR faults [Software event] task-clock [Software event] L1-dcache-load-misses [Hardware cache event] L1-dcache-loads [Hardware cache event] L1-dcache-store-misses [Hardware cache event] L1-dcache-stores [Hardware cache event] L1-icache-load-misses [Hardware cache event] L1-icache-loads [Hardware cache event] branch-load-misses [Hardware cache event] branch-loads [Hardware cache event] dTLB-load-misses [Hardware cache event] iTLB-load-misses [Hardware cache event] armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event] armv8_pmuv3_0/br_pred/ [Kernel PMU event] armv8_pmuv3_0/bus_access/ [Kernel PMU event] armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event] armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event] armv8_pmuv3_0/exc_return/ [Kernel PMU event] armv8_pmuv3_0/exc_taken/ [Kernel PMU event] armv8_pmuv3_0/inst_retired/ [Kernel PMU event] armv8_pmuv3_0/inst_spec/ [Kernel PMU event] armv8_pmuv3_0/l1d_cache/ [Kernel PMU event] armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event] armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event] armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event] armv8_pmuv3_0/l1i_cache/ [Kernel PMU event] armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event] armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event] armv8_pmuv3_0/l2d_cache/ [Kernel PMU event] armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event] armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event] armv8_pmuv3_0/mem_access/ [Kernel PMU event] armv8_pmuv3_0/memory_error/ [Kernel PMU event] armv8_pmuv3_0/sw_incr/ [Kernel PMU event] armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event] rNNN [Raw hardware event descriptor] cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor] mem:<addr>[/len][:access] [Hardwarebreakpoint] I've verified this on an APM Mustang with the FW 3.06.25. Itaru ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support
@ 2017-03-10 11:04 Mark Rutland
2017-03-10 22:14 ` Jeremy Linton
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Mark Rutland @ 2017-03-10 11:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series implements ACPI support in the ARM PMU code. It borrows some code
from Jeremy's series [1], but takes a different approach to probing and
association, using the usual hotplug state machine, minimising external changes
required, and simplifying the relationship with the common arm_pmu code.
The first few patches are preparatory cleanup/refactoring, with the latter half
of the series being specific to ACPI support.
The series is based on my IRQ rework patches [2]. I've pushed the whole series
out to the arm/perf/acpi branch [3] of my kernel.org repo.
Due to the innards of the hotplug callback framework, it's not entirely
safe to register a PMU in a hotplug callback. Due to this, we can only
associated hotplugged CPUs with a PMU if a matching CPU was around at
probe time. A similar restriction already applies to DT systems. We may
be able to relax this with some future work.
I've given this some testing on a Juno platform (using SPIs). To see that IRQs
are correctly associated, I've tested with the following:
$ taskset -c ${SOME_CPU_HERE} perf record \
-e armv8_pmuv3_0/cpu_cycles/ \
-e armv8_pmuv3_1/cpu_cycles/ \
cat /proc/interrupts
I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
association logic. This has also been tested in a VM using PPIs; I do not have
access to a host machine which itself uses PPIs.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/482397.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492891.html
[3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm/perf/acpi
Mark Rutland (14):
drivers/perf: arm_pmu: remove pointless PMU disabling
drivers/perf: arm_pmu: define armpmu_init_fn
drivers/perf: arm_pmu: fold init into alloc
drivers/perf: arm_pmu: factor out pmu registration
drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs()
drivers/perf: arm_pmu: handle no platform_device
drivers/perf: arm_pmu: rename irq request/free functions
drivers/perf: arm_pmu: split cpu-local irq request/free
drivers/perf: arm_pmu: move irq request/free into probe
drivers/perf: arm_pmu: split out platform device probe logic
arm64: add function to get a cpu's MADT GICC table
arm64: kill acpi_set_mailbox_entry()
drivers/perf: arm_pmu: add ACPI framework
arm64: pmuv3: use arm_pmu ACPI framework
arch/arm64/include/asm/acpi.h | 7 +-
arch/arm64/kernel/acpi_parking_protocol.c | 38 +--
arch/arm64/kernel/perf_event.c | 26 +-
arch/arm64/kernel/smp.c | 19 +-
drivers/perf/Kconfig | 4 +
drivers/perf/Makefile | 3 +-
drivers/perf/arm_pmu.c | 383 ++++++++----------------------
drivers/perf/arm_pmu_acpi.c | 237 ++++++++++++++++++
drivers/perf/arm_pmu_platform.c | 235 ++++++++++++++++++
include/linux/cpuhotplug.h | 1 +
include/linux/perf/arm_pmu.h | 22 +-
11 files changed, 626 insertions(+), 349 deletions(-)
create mode 100644 drivers/perf/arm_pmu_acpi.c
create mode 100644 drivers/perf/arm_pmu_platform.c
--
1.9.1
^ permalink raw reply [flat|nested] 23+ messages in thread* [PATCH 00/14] arm_pmu: ACPI support 2017-03-10 11:04 Mark Rutland @ 2017-03-10 22:14 ` Jeremy Linton 2017-03-14 11:49 ` Mark Rutland 2017-03-15 15:34 ` Mark Rutland 2017-03-16 13:00 ` Hanjun Guo 2017-03-24 21:36 ` Jeremy Linton 2 siblings, 2 replies; 23+ messages in thread From: Jeremy Linton @ 2017-03-10 22:14 UTC (permalink / raw) To: linux-arm-kernel Hi, On 03/10/2017 05:04 AM, Mark Rutland wrote: > Hi, > > This series implements ACPI support in the ARM PMU code. It borrows some code > from Jeremy's series [1], but takes a different approach to probing and > association, using the usual hotplug state machine, minimising external changes > required, and simplifying the relationship with the common arm_pmu code. > > The first few patches are preparatory cleanup/refactoring, with the latter half > of the series being specific to ACPI support. > > The series is based on my IRQ rework patches [2]. I've pushed the whole series > out to the arm/perf/acpi branch [3] of my kernel.org repo. > > Due to the innards of the hotplug callback framework, it's not entirely > safe to register a PMU in a hotplug callback. Due to this, we can only > associated hotplugged CPUs with a PMU if a matching CPU was around at > probe time. A similar restriction already applies to DT systems. We may > be able to relax this with some future work. Which is disappointing, as I thought that was one of Lorenzo's complaints about the last patch series. > > I've given this some testing on a Juno platform (using SPIs). To see that IRQs > are correctly associated, I've tested with the following: > > $ taskset -c ${SOME_CPU_HERE} perf record \ > -e armv8_pmuv3_0/cpu_cycles/ \ > -e armv8_pmuv3_1/cpu_cycles/ \ > cat /proc/interrupts > > I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the > association logic. This has also been tested in a VM using PPIs; I do not have > access to a host machine which itself uses PPIs. I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them. Although its quite possibly PEBCAK. Given that SPCR/etc is also broken and the kernel itself seems to fail if I give it a full earlycon line, I can't pin down whats going on with the PMU code until I fix the console. About the only thing it says with any meaning when earlycon is passed is: [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq and promptly hangs up. I'm OOO for the next week, and will debug this further when I return if no one else makes any progress. > > Thanks, > Mark. > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/482397.html > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492891.html > [3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm/perf/acpi > > Mark Rutland (14): > drivers/perf: arm_pmu: remove pointless PMU disabling > drivers/perf: arm_pmu: define armpmu_init_fn > drivers/perf: arm_pmu: fold init into alloc > drivers/perf: arm_pmu: factor out pmu registration > drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs() > drivers/perf: arm_pmu: handle no platform_device > drivers/perf: arm_pmu: rename irq request/free functions > drivers/perf: arm_pmu: split cpu-local irq request/free > drivers/perf: arm_pmu: move irq request/free into probe > drivers/perf: arm_pmu: split out platform device probe logic > arm64: add function to get a cpu's MADT GICC table > arm64: kill acpi_set_mailbox_entry() > drivers/perf: arm_pmu: add ACPI framework > arm64: pmuv3: use arm_pmu ACPI framework > > arch/arm64/include/asm/acpi.h | 7 +- > arch/arm64/kernel/acpi_parking_protocol.c | 38 +-- > arch/arm64/kernel/perf_event.c | 26 +- > arch/arm64/kernel/smp.c | 19 +- > drivers/perf/Kconfig | 4 + > drivers/perf/Makefile | 3 +- > drivers/perf/arm_pmu.c | 383 ++++++++---------------------- > drivers/perf/arm_pmu_acpi.c | 237 ++++++++++++++++++ > drivers/perf/arm_pmu_platform.c | 235 ++++++++++++++++++ > include/linux/cpuhotplug.h | 1 + > include/linux/perf/arm_pmu.h | 22 +- > 11 files changed, 626 insertions(+), 349 deletions(-) > create mode 100644 drivers/perf/arm_pmu_acpi.c > create mode 100644 drivers/perf/arm_pmu_platform.c > ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-10 22:14 ` Jeremy Linton @ 2017-03-14 11:49 ` Mark Rutland 2017-03-14 18:47 ` Mark Rutland 2017-03-15 15:34 ` Mark Rutland 1 sibling, 1 reply; 23+ messages in thread From: Mark Rutland @ 2017-03-14 11:49 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote: > On 03/10/2017 05:04 AM, Mark Rutland wrote: > >This series implements ACPI support in the ARM PMU code. > I tried these patches on a m400 (which uses PPIs), and the kernel > fails to come up enough to login via the network (which works with > 4.11rc1 without these patches). So, I suspect there is something > wrong with them. Indeed; sorry about this. I'll see if I can get access to a board to try local debugging. I assume that these have successfully booted with the other ACPI PMU patches? > Given that SPCR/etc is also broken and the kernel itself seems to > fail if I give it a full earlycon line, I can't pin down whats going > on with the PMU code until I fix the console. If there are known broken tables, it's possible that the MADT GICC is also broken, and we're registering/unregistering an erroneously described interrupt. > About the only thing it says with any meaning when earlycon is passed is: > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq > > and promptly hangs up. I guess that's at the point it transfers over to the real console driver. If you're not already doing so, also passing "keep_bootcon" may get more output. > I'm OOO for the next week, and will debug this further when I return > if no one else makes any progress. I'll see what I can do until then. Thanks, Mark. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-14 11:49 ` Mark Rutland @ 2017-03-14 18:47 ` Mark Rutland 2017-03-14 22:06 ` Agustin Vega-Frias 2017-03-22 12:19 ` Lorenzo Pieralisi 0 siblings, 2 replies; 23+ messages in thread From: Mark Rutland @ 2017-03-14 18:47 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote: > On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote: > > I tried these patches on a m400 (which uses PPIs), and the kernel > > fails to come up enough to login via the network (which works with > > 4.11rc1 without these patches). So, I suspect there is something > > wrong with them. > > Indeed; sorry about this. I'll see if I can get access to a board to try > local debugging. > > About the only thing it says with any meaning when earlycon is passed is: > > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq > > > > and promptly hangs up. I believe that this is a latent FW bug, in a beta FW, exposed by recent changes. I managed to get access to two APM Mustang boards. I can reproduce the issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. The same kernel boots fine on the other, which has a later released FW. I bisected the issue down to commit: d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain mapping") It seems the beta FW describes the UART interrupt with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec, this means "This device produces and consumes this resource", which doesn't make sense here given the UART is not an interrupt controller. The (working) released FW doesn't use an Extended Interrupt Descriptor for this interrupt, sidestepping the issue. Given that (AFAICT) this only affects a known-broken, beta FW, I don't think that we care that much. However, I think there is a larger potential issue here. In acpi_irq_parse_one_cb(), we skip interrupts with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. It sounds like devices which behave as interrupt controllers could legitimately have this bit set for interrupts they generate and deliver to themselves, and we'd erroneously skip these when parsing interrupts. It's not entirely clear to me why this bit exists at all, given that it's not used as part of mapping the interrupt, and if you really want to know you can map the interrupt and look at the result. Thanks, Mark. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-14 18:47 ` Mark Rutland @ 2017-03-14 22:06 ` Agustin Vega-Frias 2017-03-15 2:49 ` Hanjun Guo 2017-03-22 12:19 ` Lorenzo Pieralisi 1 sibling, 1 reply; 23+ messages in thread From: Agustin Vega-Frias @ 2017-03-14 22:06 UTC (permalink / raw) To: linux-arm-kernel Hi Mark, On 2017-03-14 14:47, Mark Rutland wrote: > On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote: >> On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote: >> > I tried these patches on a m400 (which uses PPIs), and the kernel >> > fails to come up enough to login via the network (which works with >> > 4.11rc1 without these patches). So, I suspect there is something >> > wrong with them. >> >> Indeed; sorry about this. I'll see if I can get access to a board to >> try >> local debugging. > >> > About the only thing it says with any meaning when earlycon is passed is: >> > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled >> > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq >> > >> > and promptly hangs up. > > I believe that this is a latent FW bug, in a beta FW, exposed by recent > changes. > > I managed to get access to two APM Mustang boards. I can reproduce the > issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. > The same kernel boots fine on the other, which has a later released FW. > > I bisected the issue down to commit: > > d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain > mapping") > > It seems the beta FW describes the UART interrupt with an Extended > Interrupt Descriptor with the Consumer/Producer bit clear. Per the > spec, > this means "This device produces and consumes this resource", which > doesn't make sense here given the UART is not an interrupt controller. > > The (working) released FW doesn't use an Extended Interrupt Descriptor > for this interrupt, sidestepping the issue. > > Given that (AFAICT) this only affects a known-broken, beta FW, I don't > think that we care that much. > > However, I think there is a larger potential issue here. > > In acpi_irq_parse_one_cb(), we skip interrupts with an Extended > Interrupt Descriptor with the Consumer/Producer bit clear. It sounds > like devices which behave as interrupt controllers could legitimately > have this bit set for interrupts they generate and deliver to > themselves, and we'd erroneously skip these when parsing interrupts. > > It's not entirely clear to me why this bit exists at all, given that > it's not used as part of mapping the interrupt, and if you really want > to know you can map the interrupt and look at the result. > I think the best approach would be to try to amend the spec and make zero mean producer only which is the way it is being treated in Linux. That would mean that a device consuming its own interrupts would have to have two resources, one for describing the resource as producer and one as consumer. Unfortunately the spec is vague in some areas like the feature we used to implement secondary IRQ controllers which require this patch. Hanjun, can you bring this up at the next ASWG meeting? I don't normally attend but I will ask our ASWG lead to invite me so we can discuss this in that forum. Thanks, Agustin -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-14 22:06 ` Agustin Vega-Frias @ 2017-03-15 2:49 ` Hanjun Guo 0 siblings, 0 replies; 23+ messages in thread From: Hanjun Guo @ 2017-03-15 2:49 UTC (permalink / raw) To: linux-arm-kernel On 2017/3/15 6:06, Agustin Vega-Frias wrote: > Hi Mark, > > On 2017-03-14 14:47, Mark Rutland wrote: >> On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote: >>> On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote: >>> > I tried these patches on a m400 (which uses PPIs), and the kernel >>> > fails to come up enough to login via the network (which works with >>> > 4.11rc1 without these patches). So, I suspect there is something >>> > wrong with them. >>> >>> Indeed; sorry about this. I'll see if I can get access to a board to try >>> local debugging. >> >>> > About the only thing it says with any meaning when earlycon is >>> passed is: >>> > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing >>> enabled >>> > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq >>> > >>> > and promptly hangs up. >> >> I believe that this is a latent FW bug, in a beta FW, exposed by recent >> changes. >> >> I managed to get access to two APM Mustang boards. I can reproduce the >> issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. >> The same kernel boots fine on the other, which has a later released FW. >> >> I bisected the issue down to commit: >> >> d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain >> mapping") >> >> It seems the beta FW describes the UART interrupt with an Extended >> Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec, >> this means "This device produces and consumes this resource", which >> doesn't make sense here given the UART is not an interrupt controller. >> >> The (working) released FW doesn't use an Extended Interrupt Descriptor >> for this interrupt, sidestepping the issue. >> >> Given that (AFAICT) this only affects a known-broken, beta FW, I don't >> think that we care that much. >> >> However, I think there is a larger potential issue here. >> >> In acpi_irq_parse_one_cb(), we skip interrupts with an Extended >> Interrupt Descriptor with the Consumer/Producer bit clear. It sounds >> like devices which behave as interrupt controllers could legitimately >> have this bit set for interrupts they generate and deliver to >> themselves, and we'd erroneously skip these when parsing interrupts. >> >> It's not entirely clear to me why this bit exists at all, given that >> it's not used as part of mapping the interrupt, and if you really want >> to know you can map the interrupt and look at the result. >> > > I think the best approach would be to try to amend the spec and make > zero mean producer only which is the way it is being treated in Linux. > That would mean that a device consuming its own interrupts would have to > have two resources, one for describing the resource as producer and one > as consumer. Agreed. I think it's a typo in the spec, should be only produce resource if it's 0, and that's the behavior in ACPICA core now (both used by linux kernel and windows). > > Unfortunately the spec is vague in some areas like the feature we used > to implement secondary IRQ controllers which require this patch. > > Hanjun, can you bring this up at the next ASWG meeting? I don't normally > attend but I will ask our ASWG lead to invite me so we can discuss this > in that forum. I will do that, and I will send an email to report this issue first with you and Mark CCed. Thanks Hanjun ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-14 18:47 ` Mark Rutland 2017-03-14 22:06 ` Agustin Vega-Frias @ 2017-03-22 12:19 ` Lorenzo Pieralisi 2017-03-22 14:06 ` Agustin Vega-Frias 2017-03-22 23:23 ` Hanjun Guo 1 sibling, 2 replies; 23+ messages in thread From: Lorenzo Pieralisi @ 2017-03-22 12:19 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 14, 2017 at 06:47:34PM +0000, Mark Rutland wrote: > On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote: > > On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote: > > > I tried these patches on a m400 (which uses PPIs), and the kernel > > > fails to come up enough to login via the network (which works with > > > 4.11rc1 without these patches). So, I suspect there is something > > > wrong with them. > > > > Indeed; sorry about this. I'll see if I can get access to a board to try > > local debugging. > > > > About the only thing it says with any meaning when earlycon is passed is: > > > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > > > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq > > > > > > and promptly hangs up. > > I believe that this is a latent FW bug, in a beta FW, exposed by recent > changes. > > I managed to get access to two APM Mustang boards. I can reproduce the > issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. > The same kernel boots fine on the other, which has a later released FW. > > I bisected the issue down to commit: > > d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain mapping") > > It seems the beta FW describes the UART interrupt with an Extended > Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec, > this means "This device produces and consumes this resource", which > doesn't make sense here given the UART is not an interrupt controller. > > The (working) released FW doesn't use an Extended Interrupt Descriptor > for this interrupt, sidestepping the issue. > > Given that (AFAICT) this only affects a known-broken, beta FW, I don't > think that we care that much. > > However, I think there is a larger potential issue here. > > In acpi_irq_parse_one_cb(), we skip interrupts with an Extended > Interrupt Descriptor with the Consumer/Producer bit clear. It sounds > like devices which behave as interrupt controllers could legitimately > have this bit set for interrupts they generate and deliver to > themselves, and we'd erroneously skip these when parsing interrupts. > > It's not entirely clear to me why this bit exists at all, given that > it's not used as part of mapping the interrupt, and if you really want > to know you can map the interrupt and look at the result. It is not entirely clear to anyone (and it has been a source of major trouble for other descriptors - ie memory - to the point that it has been deprecated for *some* descriptors). IIRC (Hanjun ?) the only reason why Agustin added the check for that bit in drivers/acpi/resource.c (is_gsi()) is to prevent ACPI core code allocating IRQs for the MBIgen device that, _erroneously_, was using an extended interrupt descriptor to list IRQ lines (that I have no idea what they represent) in order to count how many MSI vectors it would have to allocate. The gist is: removing the check for the extended interrupt descriptor producer/consumer bit in ACPI code therefore ignoring that bit should be harmless (given that the MBIgen bindings should be changed anyway). The meaning of that bit (and how we can flag up a FW bug) it is still a bit fuzzy IMO. Agustin, Hanjun, comments ? Lorenzo ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-22 12:19 ` Lorenzo Pieralisi @ 2017-03-22 14:06 ` Agustin Vega-Frias 2017-03-22 23:23 ` Hanjun Guo 1 sibling, 0 replies; 23+ messages in thread From: Agustin Vega-Frias @ 2017-03-22 14:06 UTC (permalink / raw) To: linux-arm-kernel Hi Lorenzo, On 2017-03-22 08:19, Lorenzo Pieralisi wrote: > On Tue, Mar 14, 2017 at 06:47:34PM +0000, Mark Rutland wrote: >> On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote: >> > On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote: >> > > I tried these patches on a m400 (which uses PPIs), and the kernel >> > > fails to come up enough to login via the network (which works with >> > > 4.11rc1 without these patches). So, I suspect there is something >> > > wrong with them. >> > >> > Indeed; sorry about this. I'll see if I can get access to a board to try >> > local debugging. >> >> > > About the only thing it says with any meaning when earlycon is passed is: >> > > [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled >> > > [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq >> > > >> > > and promptly hangs up. >> >> I believe that this is a latent FW bug, in a beta FW, exposed by >> recent >> changes. >> >> I managed to get access to two APM Mustang boards. I can reproduce the >> issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. >> The same kernel boots fine on the other, which has a later released >> FW. >> >> I bisected the issue down to commit: >> >> d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain >> mapping") >> >> It seems the beta FW describes the UART interrupt with an Extended >> Interrupt Descriptor with the Consumer/Producer bit clear. Per the >> spec, >> this means "This device produces and consumes this resource", which >> doesn't make sense here given the UART is not an interrupt controller. >> >> The (working) released FW doesn't use an Extended Interrupt Descriptor >> for this interrupt, sidestepping the issue. >> >> Given that (AFAICT) this only affects a known-broken, beta FW, I don't >> think that we care that much. >> >> However, I think there is a larger potential issue here. >> >> In acpi_irq_parse_one_cb(), we skip interrupts with an Extended >> Interrupt Descriptor with the Consumer/Producer bit clear. It sounds >> like devices which behave as interrupt controllers could legitimately >> have this bit set for interrupts they generate and deliver to >> themselves, and we'd erroneously skip these when parsing interrupts. >> >> It's not entirely clear to me why this bit exists at all, given that >> it's not used as part of mapping the interrupt, and if you really want >> to know you can map the interrupt and look at the result. > > It is not entirely clear to anyone (and it has been a source of major > trouble for other descriptors - ie memory - to the point that it has > been > deprecated for *some* descriptors). IIRC (Hanjun ?) the only reason why > Agustin added the check for that bit in drivers/acpi/resource.c > (is_gsi()) is to prevent ACPI core code allocating IRQs for the MBIgen > device that, _erroneously_, was using an extended interrupt descriptor > to list IRQ lines (that I have no idea what they represent) in order to > count how many MSI vectors it would have to allocate. > > The gist is: removing the check for the extended interrupt descriptor > producer/consumer bit in ACPI code therefore ignoring that bit should > be harmless (given that the MBIgen bindings should be changed anyway). > > The meaning of that bit (and how we can flag up a FW bug) it is still > a bit fuzzy IMO. > > Agustin, Hanjun, comments ? > Yes, that was the reason the check was added, if MBIgen will use a different mechanism to describe the IRQs it produces we can remove the check. I'd still like for the ASWG to get to the bottom of the issue, given that the resource descriptor and the macro definitions contradict each other. Hanjun, was this discussed on last week's meeting? Thanks, Agustin -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-22 12:19 ` Lorenzo Pieralisi 2017-03-22 14:06 ` Agustin Vega-Frias @ 2017-03-22 23:23 ` Hanjun Guo 1 sibling, 0 replies; 23+ messages in thread From: Hanjun Guo @ 2017-03-22 23:23 UTC (permalink / raw) To: linux-arm-kernel On 03/22/2017 08:19 PM, Lorenzo Pieralisi wrote: > On Tue, Mar 14, 2017 at 06:47:34PM +0000, Mark Rutland wrote: >> On Tue, Mar 14, 2017 at 11:49:19AM +0000, Mark Rutland wrote: >>> On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote: >>>> I tried these patches on a m400 (which uses PPIs), and the kernel >>>> fails to come up enough to login via the network (which works with >>>> 4.11rc1 without these patches). So, I suspect there is something >>>> wrong with them. >>> >>> Indeed; sorry about this. I'll see if I can get access to a board to try >>> local debugging. >> >>>> About the only thing it says with any meaning when earlycon is passed is: >>>> [ 10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled >>>> [ 11.064193] dw-apb-uart APMC0D08:00: cannot get irq >>>> >>>> and promptly hangs up. >> >> I believe that this is a latent FW bug, in a beta FW, exposed by recent >> changes. >> >> I managed to get access to two APM Mustang boards. I can reproduce the >> issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. >> The same kernel boots fine on the other, which has a later released FW. >> >> I bisected the issue down to commit: >> >> d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain mapping") >> >> It seems the beta FW describes the UART interrupt with an Extended >> Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec, >> this means "This device produces and consumes this resource", which >> doesn't make sense here given the UART is not an interrupt controller. >> >> The (working) released FW doesn't use an Extended Interrupt Descriptor >> for this interrupt, sidestepping the issue. >> >> Given that (AFAICT) this only affects a known-broken, beta FW, I don't >> think that we care that much. >> >> However, I think there is a larger potential issue here. >> >> In acpi_irq_parse_one_cb(), we skip interrupts with an Extended >> Interrupt Descriptor with the Consumer/Producer bit clear. It sounds >> like devices which behave as interrupt controllers could legitimately >> have this bit set for interrupts they generate and deliver to >> themselves, and we'd erroneously skip these when parsing interrupts. >> >> It's not entirely clear to me why this bit exists at all, given that >> it's not used as part of mapping the interrupt, and if you really want >> to know you can map the interrupt and look at the result. > > It is not entirely clear to anyone (and it has been a source of major > trouble for other descriptors - ie memory - to the point that it has been > deprecated for *some* descriptors). IIRC (Hanjun ?) the only reason why > Agustin added the check for that bit in drivers/acpi/resource.c > (is_gsi()) is to prevent ACPI core code allocating IRQs for the MBIgen > device that, _erroneously_, was using an extended interrupt descriptor > to list IRQ lines (that I have no idea what they represent) in order to > count how many MSI vectors it would have to allocate. I'm not sure it's error for a interrupt producer device (such as MBIgen) to represent its interrupt resources using Interrupt under _CRS, from the spec, we didn't violate anything, but in the OS side we expect a better way to count MSI vectors. > > The gist is: removing the check for the extended interrupt descriptor > producer/consumer bit in ACPI code therefore ignoring that bit should > be harmless (given that the MBIgen bindings should be changed anyway). > > The meaning of that bit (and how we can flag up a FW bug) it is still > a bit fuzzy IMO. > > Agustin, Hanjun, comments ? I think it's firmware bug in the first place, PRODUCER bit can't be clear if the device itself is not an interrupt controller, as we can see that it's UART interrupt and UART can't be a interrupt controller right? and the default value for the Consumer/Producer bit is 1, not 0, the spec clearly say that. So I think we need to fix the firmware (then the code is still not violate any platforms), and also we need to fix the spec to clarify things (As Agustin proposed), I reported this issue to ASWG but seems my email was blocked, I will raise an ECR for discussion. Thanks Hanjun ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-10 22:14 ` Jeremy Linton 2017-03-14 11:49 ` Mark Rutland @ 2017-03-15 15:34 ` Mark Rutland 1 sibling, 0 replies; 23+ messages in thread From: Mark Rutland @ 2017-03-15 15:34 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 10, 2017 at 04:14:57PM -0600, Jeremy Linton wrote: > On 03/10/2017 05:04 AM, Mark Rutland wrote: > >I've given this some testing on a Juno platform (using SPIs). To see that IRQs > >are correctly associated, I've tested with the following: > > > > $ taskset -c ${SOME_CPU_HERE} perf record \ > > -e armv8_pmuv3_0/cpu_cycles/ \ > > -e armv8_pmuv3_1/cpu_cycles/ \ > > cat /proc/interrupts > > > >I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the > >association logic. This has also been tested in a VM using PPIs; I do not have > >access to a host machine which itself uses PPIs. > > I tried these patches on a m400 (which uses PPIs), and the kernel > fails to come up enough to login via the network (which works with > 4.11rc1 without these patches). So, I suspect there is something > wrong with them. Although its quite possibly PEBCAK. It looks like we've gotten to the bottom of the hang in the other thread; I had a go with a hack to bodge around that (as I have not yet upgraded the FW). I had a go with the above taskset pattern (limited to a single PMU) on an APM Mustang board. Everything seems happy, even when I booted with maxcpus temporarily capped, where CPUs successfully associated themselves with the PMU later on. Thanks, Mark. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-10 11:04 Mark Rutland 2017-03-10 22:14 ` Jeremy Linton @ 2017-03-16 13:00 ` Hanjun Guo 2017-03-20 18:11 ` Ganapatrao Kulkarni 2017-03-24 21:36 ` Jeremy Linton 2 siblings, 1 reply; 23+ messages in thread From: Hanjun Guo @ 2017-03-16 13:00 UTC (permalink / raw) To: linux-arm-kernel On 2017/3/10 19:04, Mark Rutland wrote: > Hi, > > This series implements ACPI support in the ARM PMU code. It borrows some code > from Jeremy's series [1], but takes a different approach to probing and > association, using the usual hotplug state machine, minimising external changes > required, and simplifying the relationship with the common arm_pmu code. > > The first few patches are preparatory cleanup/refactoring, with the latter half > of the series being specific to ACPI support. > > The series is based on my IRQ rework patches [2]. I've pushed the whole series > out to the arm/perf/acpi branch [3] of my kernel.org repo. > > Due to the innards of the hotplug callback framework, it's not entirely > safe to register a PMU in a hotplug callback. Due to this, we can only > associated hotplugged CPUs with a PMU if a matching CPU was around at > probe time. A similar restriction already applies to DT systems. We may > be able to relax this with some future work. > > I've given this some testing on a Juno platform (using SPIs). To see that IRQs > are correctly associated, I've tested with the following: > > $ taskset -c ${SOME_CPU_HERE} perf record \ > -e armv8_pmuv3_0/cpu_cycles/ \ > -e armv8_pmuv3_1/cpu_cycles/ \ > cat /proc/interrupts > > I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the > association logic. This has also been tested in a VM using PPIs; I do not have > access to a host machine which itself uses PPIs. Booted OK and 'perf list' got on Hisilicon D03: d03-09:~ # perf list List of pre-defined events (to be used in -e): branch-misses [Hardware event] bus-cycles [Hardware event] cache-misses [Hardware event] cache-references [Hardware event] cpu-cycles OR cycles [Hardware event] instructions [Hardware event] alignment-faults [Software event] context-switches OR cs [Software event] cpu-clock [Software event] cpu-migrations OR migrations [Software event] dummy [Software event] emulation-faults [Software event] major-faults [Software event] minor-faults [Software event] page-faults OR faults [Software event] task-clock [Software event] L1-dcache-load-misses [Hardware cache event] L1-dcache-loads [Hardware cache event] L1-dcache-store-misses [Hardware cache event] L1-dcache-stores [Hardware cache event] L1-icache-load-misses [Hardware cache event] L1-icache-loads [Hardware cache event] branch-load-misses [Hardware cache event] branch-loads [Hardware cache event] dTLB-load-misses [Hardware cache event] iTLB-load-misses [Hardware cache event] armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event] armv8_pmuv3_0/br_pred/ [Kernel PMU event] armv8_pmuv3_0/bus_access/ [Kernel PMU event] armv8_pmuv3_0/bus_cycles/ [Kernel PMU event] armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event] armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event] armv8_pmuv3_0/exc_return/ [Kernel PMU event] armv8_pmuv3_0/exc_taken/ [Kernel PMU event] armv8_pmuv3_0/inst_retired/ [Kernel PMU event] armv8_pmuv3_0/inst_spec/ [Kernel PMU event] armv8_pmuv3_0/l1d_cache/ [Kernel PMU event] armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event] armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event] armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event] armv8_pmuv3_0/l1i_cache/ [Kernel PMU event] armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event] armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event] armv8_pmuv3_0/l2d_cache/ [Kernel PMU event] armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event] armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event] armv8_pmuv3_0/mem_access/ [Kernel PMU event] armv8_pmuv3_0/memory_error/ [Kernel PMU event] armv8_pmuv3_0/sw_incr/ [Kernel PMU event] armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event] rNNN [Raw hardware event descriptor] cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor] (see 'man perf-list' on how to encode it) mem:<addr>[/len][:access] [Hardware breakpoint] Try some basic perf event and it works, anything else I can try in specific? Thanks Hanjun ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-16 13:00 ` Hanjun Guo @ 2017-03-20 18:11 ` Ganapatrao Kulkarni 2017-03-22 9:16 ` Ganapatrao Kulkarni 2017-04-11 9:32 ` Hanjun Guo 0 siblings, 2 replies; 23+ messages in thread From: Ganapatrao Kulkarni @ 2017-03-20 18:11 UTC (permalink / raw) To: linux-arm-kernel Hi Hanjun, On Thu, Mar 16, 2017 at 6:30 PM, Hanjun Guo <guohanjun@huawei.com> wrote: > On 2017/3/10 19:04, Mark Rutland wrote: >> Hi, >> >> This series implements ACPI support in the ARM PMU code. It borrows some code >> from Jeremy's series [1], but takes a different approach to probing and >> association, using the usual hotplug state machine, minimising external changes >> required, and simplifying the relationship with the common arm_pmu code. >> >> The first few patches are preparatory cleanup/refactoring, with the latter half >> of the series being specific to ACPI support. >> >> The series is based on my IRQ rework patches [2]. I've pushed the whole series >> out to the arm/perf/acpi branch [3] of my kernel.org repo. >> >> Due to the innards of the hotplug callback framework, it's not entirely >> safe to register a PMU in a hotplug callback. Due to this, we can only >> associated hotplugged CPUs with a PMU if a matching CPU was around at >> probe time. A similar restriction already applies to DT systems. We may >> be able to relax this with some future work. >> >> I've given this some testing on a Juno platform (using SPIs). To see that IRQs >> are correctly associated, I've tested with the following: >> >> $ taskset -c ${SOME_CPU_HERE} perf record \ >> -e armv8_pmuv3_0/cpu_cycles/ \ >> -e armv8_pmuv3_1/cpu_cycles/ \ >> cat /proc/interrupts >> >> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the >> association logic. This has also been tested in a VM using PPIs; I do not have >> access to a host machine which itself uses PPIs. > > Booted OK and 'perf list' got on Hisilicon D03: > > d03-09:~ # perf list > > List of pre-defined events (to be used in -e): > > branch-misses [Hardware event] > bus-cycles [Hardware event] > cache-misses [Hardware event] > cache-references [Hardware event] > cpu-cycles OR cycles [Hardware event] > instructions [Hardware event] > > alignment-faults [Software event] > context-switches OR cs [Software event] > cpu-clock [Software event] > cpu-migrations OR migrations [Software event] > dummy [Software event] > emulation-faults [Software event] > major-faults [Software event] > minor-faults [Software event] > page-faults OR faults [Software event] > task-clock [Software event] > > L1-dcache-load-misses [Hardware cache event] > L1-dcache-loads [Hardware cache event] > L1-dcache-store-misses [Hardware cache event] > L1-dcache-stores [Hardware cache event] > L1-icache-load-misses [Hardware cache event] > L1-icache-loads [Hardware cache event] > branch-load-misses [Hardware cache event] > branch-loads [Hardware cache event] > dTLB-load-misses [Hardware cache event] > iTLB-load-misses [Hardware cache event] > > armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event] > armv8_pmuv3_0/br_pred/ [Kernel PMU event] > armv8_pmuv3_0/bus_access/ [Kernel PMU event] > armv8_pmuv3_0/bus_cycles/ [Kernel PMU event] > armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event] > armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event] > armv8_pmuv3_0/exc_return/ [Kernel PMU event] > armv8_pmuv3_0/exc_taken/ [Kernel PMU event] > armv8_pmuv3_0/inst_retired/ [Kernel PMU event] > armv8_pmuv3_0/inst_spec/ [Kernel PMU event] > armv8_pmuv3_0/l1d_cache/ [Kernel PMU event] > armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event] > armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event] > armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event] > armv8_pmuv3_0/l1i_cache/ [Kernel PMU event] > armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event] > armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event] > armv8_pmuv3_0/l2d_cache/ [Kernel PMU event] > armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event] > armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event] > armv8_pmuv3_0/mem_access/ [Kernel PMU event] > armv8_pmuv3_0/memory_error/ [Kernel PMU event] > armv8_pmuv3_0/sw_incr/ [Kernel PMU event] > armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event] > > rNNN [Raw hardware event descriptor] > cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor] > (see 'man perf-list' on how to encode it) > > mem:<addr>[/len][:access] [Hardware breakpoint] > > > Try some basic perf event and it works, anything else I can try in specific? you can try perf fuzzer thanks Ganapat > > Thanks > Hanjun > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-20 18:11 ` Ganapatrao Kulkarni @ 2017-03-22 9:16 ` Ganapatrao Kulkarni 2017-03-22 15:59 ` Mark Rutland 2017-04-03 10:41 ` Ganapatrao Kulkarni 2017-04-11 9:32 ` Hanjun Guo 1 sibling, 2 replies; 23+ messages in thread From: Ganapatrao Kulkarni @ 2017-03-22 9:16 UTC (permalink / raw) To: linux-arm-kernel i am not able to run with latest perf tool, i see issue with memory corruption in malloc is this seen from anyone else too? i am not sure, is this issue with my setup? root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 Performance counter stats for 'sleep 1': 10,815 armv8_pmuv3_0/br_mis_pred/ 1.001232167 seconds time elapsed root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 *** Aborted (core dumped) root at VAL1-13>perf>> ./perf -v perf version 4.11.rc3.g093b99 root at VAL1-13>perf>> perf -v perf version 4.8.rc6.g21c488 root at VAL1-13>perf>> uname -a Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux root at VAL1-13>perf>> On Mon, Mar 20, 2017 at 11:41 PM, Ganapatrao Kulkarni <gpkulkarni@gmail.com> wrote: > Hi Hanjun, > > On Thu, Mar 16, 2017 at 6:30 PM, Hanjun Guo <guohanjun@huawei.com> wrote: >> On 2017/3/10 19:04, Mark Rutland wrote: >>> Hi, >>> >>> This series implements ACPI support in the ARM PMU code. It borrows some code >>> from Jeremy's series [1], but takes a different approach to probing and >>> association, using the usual hotplug state machine, minimising external changes >>> required, and simplifying the relationship with the common arm_pmu code. >>> >>> The first few patches are preparatory cleanup/refactoring, with the latter half >>> of the series being specific to ACPI support. >>> >>> The series is based on my IRQ rework patches [2]. I've pushed the whole series >>> out to the arm/perf/acpi branch [3] of my kernel.org repo. >>> >>> Due to the innards of the hotplug callback framework, it's not entirely >>> safe to register a PMU in a hotplug callback. Due to this, we can only >>> associated hotplugged CPUs with a PMU if a matching CPU was around at >>> probe time. A similar restriction already applies to DT systems. We may >>> be able to relax this with some future work. >>> >>> I've given this some testing on a Juno platform (using SPIs). To see that IRQs >>> are correctly associated, I've tested with the following: >>> >>> $ taskset -c ${SOME_CPU_HERE} perf record \ >>> -e armv8_pmuv3_0/cpu_cycles/ \ >>> -e armv8_pmuv3_1/cpu_cycles/ \ >>> cat /proc/interrupts >>> >>> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the >>> association logic. This has also been tested in a VM using PPIs; I do not have >>> access to a host machine which itself uses PPIs. >> >> Booted OK and 'perf list' got on Hisilicon D03: >> >> d03-09:~ # perf list >> >> List of pre-defined events (to be used in -e): >> >> branch-misses [Hardware event] >> bus-cycles [Hardware event] >> cache-misses [Hardware event] >> cache-references [Hardware event] >> cpu-cycles OR cycles [Hardware event] >> instructions [Hardware event] >> >> alignment-faults [Software event] >> context-switches OR cs [Software event] >> cpu-clock [Software event] >> cpu-migrations OR migrations [Software event] >> dummy [Software event] >> emulation-faults [Software event] >> major-faults [Software event] >> minor-faults [Software event] >> page-faults OR faults [Software event] >> task-clock [Software event] >> >> L1-dcache-load-misses [Hardware cache event] >> L1-dcache-loads [Hardware cache event] >> L1-dcache-store-misses [Hardware cache event] >> L1-dcache-stores [Hardware cache event] >> L1-icache-load-misses [Hardware cache event] >> L1-icache-loads [Hardware cache event] >> branch-load-misses [Hardware cache event] >> branch-loads [Hardware cache event] >> dTLB-load-misses [Hardware cache event] >> iTLB-load-misses [Hardware cache event] >> >> armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event] >> armv8_pmuv3_0/br_pred/ [Kernel PMU event] >> armv8_pmuv3_0/bus_access/ [Kernel PMU event] >> armv8_pmuv3_0/bus_cycles/ [Kernel PMU event] >> armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event] >> armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event] >> armv8_pmuv3_0/exc_return/ [Kernel PMU event] >> armv8_pmuv3_0/exc_taken/ [Kernel PMU event] >> armv8_pmuv3_0/inst_retired/ [Kernel PMU event] >> armv8_pmuv3_0/inst_spec/ [Kernel PMU event] >> armv8_pmuv3_0/l1d_cache/ [Kernel PMU event] >> armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event] >> armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l1i_cache/ [Kernel PMU event] >> armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l2d_cache/ [Kernel PMU event] >> armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event] >> armv8_pmuv3_0/mem_access/ [Kernel PMU event] >> armv8_pmuv3_0/memory_error/ [Kernel PMU event] >> armv8_pmuv3_0/sw_incr/ [Kernel PMU event] >> armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event] >> >> rNNN [Raw hardware event descriptor] >> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor] >> (see 'man perf-list' on how to encode it) >> >> mem:<addr>[/len][:access] [Hardware breakpoint] >> >> >> Try some basic perf event and it works, anything else I can try in specific? > > you can try perf fuzzer > > thanks > Ganapat > >> >> Thanks >> Hanjun >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel thanks Ganapat ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-22 9:16 ` Ganapatrao Kulkarni @ 2017-03-22 15:59 ` Mark Rutland 2017-04-03 10:41 ` Ganapatrao Kulkarni 1 sibling, 0 replies; 23+ messages in thread From: Mark Rutland @ 2017-03-22 15:59 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 22, 2017 at 02:46:50PM +0530, Ganapatrao Kulkarni wrote: > i am not able to run with latest perf tool, i see issue with memory > corruption in malloc > is this seen from anyone else too? > i am not sure, is this issue with my setup? > > root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 > > Performance counter stats for 'sleep 1': > > 10,815 armv8_pmuv3_0/br_mis_pred/ > > 1.001232167 seconds time elapsed > > root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 > *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 *** > Aborted (core dumped) > root at VAL1-13>perf>> ./perf -v > perf version 4.11.rc3.g093b99 > root at VAL1-13>perf>> perf -v > perf version 4.8.rc6.g21c488 > root at VAL1-13>perf>> uname -a > Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22 > 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux > root at VAL1-13>perf>> I've managed to reproduce this on a Seatle system using DT, with the perf tool from v4.11-rc3. I'm digging into this now. Thanks, Mark. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-22 9:16 ` Ganapatrao Kulkarni 2017-03-22 15:59 ` Mark Rutland @ 2017-04-03 10:41 ` Ganapatrao Kulkarni 2017-04-03 11:12 ` Mark Rutland 1 sibling, 1 reply; 23+ messages in thread From: Ganapatrao Kulkarni @ 2017-04-03 10:41 UTC (permalink / raw) To: linux-arm-kernel Hi Mark, On Wed, Mar 22, 2017 at 2:46 PM, Ganapatrao Kulkarni <gpkulkarni@gmail.com> wrote: > i am not able to run with latest perf tool, i see issue with memory > corruption in malloc > is this seen from anyone else too? > i am not sure, is this issue with my setup? > > root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 > > Performance counter stats for 'sleep 1': > > 10,815 armv8_pmuv3_0/br_mis_pred/ > > 1.001232167 seconds time elapsed > > root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 > *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 *** > Aborted (core dumped) > root at VAL1-13>perf>> ./perf -v > perf version 4.11.rc3.g093b99 > root at VAL1-13>perf>> perf -v > perf version 4.8.rc6.g21c488 > root at VAL1-13>perf>> uname -a > Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22 > 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux > root at VAL1-13>perf>> > i did bisect, and i see your patch, 7e3fcffe955440101493cd8f32f75840ddf87b6f perf pmu: Support alternative sysfs cpumask is causing this failure. if i suppress the call to function cpu_map__read then memory corruption is not seen. > > On Mon, Mar 20, 2017 at 11:41 PM, Ganapatrao Kulkarni > <gpkulkarni@gmail.com> wrote: >> Hi Hanjun, >> >> On Thu, Mar 16, 2017 at 6:30 PM, Hanjun Guo <guohanjun@huawei.com> wrote: >>> On 2017/3/10 19:04, Mark Rutland wrote: >>>> Hi, >>>> >>>> This series implements ACPI support in the ARM PMU code. It borrows some code >>>> from Jeremy's series [1], but takes a different approach to probing and >>>> association, using the usual hotplug state machine, minimising external changes >>>> required, and simplifying the relationship with the common arm_pmu code. >>>> >>>> The first few patches are preparatory cleanup/refactoring, with the latter half >>>> of the series being specific to ACPI support. >>>> >>>> The series is based on my IRQ rework patches [2]. I've pushed the whole series >>>> out to the arm/perf/acpi branch [3] of my kernel.org repo. >>>> >>>> Due to the innards of the hotplug callback framework, it's not entirely >>>> safe to register a PMU in a hotplug callback. Due to this, we can only >>>> associated hotplugged CPUs with a PMU if a matching CPU was around at >>>> probe time. A similar restriction already applies to DT systems. We may >>>> be able to relax this with some future work. >>>> >>>> I've given this some testing on a Juno platform (using SPIs). To see that IRQs >>>> are correctly associated, I've tested with the following: >>>> >>>> $ taskset -c ${SOME_CPU_HERE} perf record \ >>>> -e armv8_pmuv3_0/cpu_cycles/ \ >>>> -e armv8_pmuv3_1/cpu_cycles/ \ >>>> cat /proc/interrupts >>>> >>>> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the >>>> association logic. This has also been tested in a VM using PPIs; I do not have >>>> access to a host machine which itself uses PPIs. >>> >>> Booted OK and 'perf list' got on Hisilicon D03: >>> >>> d03-09:~ # perf list >>> >>> List of pre-defined events (to be used in -e): >>> >>> branch-misses [Hardware event] >>> bus-cycles [Hardware event] >>> cache-misses [Hardware event] >>> cache-references [Hardware event] >>> cpu-cycles OR cycles [Hardware event] >>> instructions [Hardware event] >>> >>> alignment-faults [Software event] >>> context-switches OR cs [Software event] >>> cpu-clock [Software event] >>> cpu-migrations OR migrations [Software event] >>> dummy [Software event] >>> emulation-faults [Software event] >>> major-faults [Software event] >>> minor-faults [Software event] >>> page-faults OR faults [Software event] >>> task-clock [Software event] >>> >>> L1-dcache-load-misses [Hardware cache event] >>> L1-dcache-loads [Hardware cache event] >>> L1-dcache-store-misses [Hardware cache event] >>> L1-dcache-stores [Hardware cache event] >>> L1-icache-load-misses [Hardware cache event] >>> L1-icache-loads [Hardware cache event] >>> branch-load-misses [Hardware cache event] >>> branch-loads [Hardware cache event] >>> dTLB-load-misses [Hardware cache event] >>> iTLB-load-misses [Hardware cache event] >>> >>> armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event] >>> armv8_pmuv3_0/br_pred/ [Kernel PMU event] >>> armv8_pmuv3_0/bus_access/ [Kernel PMU event] >>> armv8_pmuv3_0/bus_cycles/ [Kernel PMU event] >>> armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event] >>> armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event] >>> armv8_pmuv3_0/exc_return/ [Kernel PMU event] >>> armv8_pmuv3_0/exc_taken/ [Kernel PMU event] >>> armv8_pmuv3_0/inst_retired/ [Kernel PMU event] >>> armv8_pmuv3_0/inst_spec/ [Kernel PMU event] >>> armv8_pmuv3_0/l1d_cache/ [Kernel PMU event] >>> armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event] >>> armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event] >>> armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event] >>> armv8_pmuv3_0/l1i_cache/ [Kernel PMU event] >>> armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event] >>> armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event] >>> armv8_pmuv3_0/l2d_cache/ [Kernel PMU event] >>> armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event] >>> armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event] >>> armv8_pmuv3_0/mem_access/ [Kernel PMU event] >>> armv8_pmuv3_0/memory_error/ [Kernel PMU event] >>> armv8_pmuv3_0/sw_incr/ [Kernel PMU event] >>> armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event] >>> >>> rNNN [Raw hardware event descriptor] >>> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor] >>> (see 'man perf-list' on how to encode it) >>> >>> mem:<addr>[/len][:access] [Hardware breakpoint] >>> >>> >>> Try some basic perf event and it works, anything else I can try in specific? >> >> you can try perf fuzzer >> >> thanks >> Ganapat >> >>> >>> Thanks >>> Hanjun >>> >>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel at lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > thanks > Ganapat thanks Ganapat ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-04-03 10:41 ` Ganapatrao Kulkarni @ 2017-04-03 11:12 ` Mark Rutland 0 siblings, 0 replies; 23+ messages in thread From: Mark Rutland @ 2017-04-03 11:12 UTC (permalink / raw) To: linux-arm-kernel Hi, On Mon, Apr 03, 2017 at 04:11:42PM +0530, Ganapatrao Kulkarni wrote: > On Wed, Mar 22, 2017 at 2:46 PM, Ganapatrao Kulkarni > <gpkulkarni@gmail.com> wrote: > > i am not able to run with latest perf tool, i see issue with memory > > corruption in malloc > > is this seen from anyone else too? > > i am not sure, is this issue with my setup? > > > > root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 > > > > Performance counter stats for 'sleep 1': > > > > 10,815 armv8_pmuv3_0/br_mis_pred/ > > > > 1.001232167 seconds time elapsed > > > > root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 > > *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 *** > > Aborted (core dumped) > > root at VAL1-13>perf>> ./perf -v > > perf version 4.11.rc3.g093b99 > > root at VAL1-13>perf>> perf -v > > perf version 4.8.rc6.g21c488 > > root at VAL1-13>perf>> uname -a > > Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22 > > 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux > > root at VAL1-13>perf>> > > i did bisect, and i see your patch, > > 7e3fcffe955440101493cd8f32f75840ddf87b6f > perf pmu: Support alternative sysfs cpumask > > is causing this failure. if i suppress the call to function cpu_map__read > then memory corruption is not seen. Thanks for tracking this down. I can reproduce this on some machines; I'll try to see how this can be fixed shortly. Thanks, Mark. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-20 18:11 ` Ganapatrao Kulkarni 2017-03-22 9:16 ` Ganapatrao Kulkarni @ 2017-04-11 9:32 ` Hanjun Guo 1 sibling, 0 replies; 23+ messages in thread From: Hanjun Guo @ 2017-04-11 9:32 UTC (permalink / raw) To: linux-arm-kernel On 2017/3/21 2:11, Ganapatrao Kulkarni wrote: > Hi Hanjun, > > On Thu, Mar 16, 2017 at 6:30 PM, Hanjun Guo <guohanjun@huawei.com> wrote: >> On 2017/3/10 19:04, Mark Rutland wrote: >>> Hi, >>> >>> This series implements ACPI support in the ARM PMU code. It borrows some code >>> from Jeremy's series [1], but takes a different approach to probing and >>> association, using the usual hotplug state machine, minimising external changes >>> required, and simplifying the relationship with the common arm_pmu code. >>> >>> The first few patches are preparatory cleanup/refactoring, with the latter half >>> of the series being specific to ACPI support. >>> >>> The series is based on my IRQ rework patches [2]. I've pushed the whole series >>> out to the arm/perf/acpi branch [3] of my kernel.org repo. >>> >>> Due to the innards of the hotplug callback framework, it's not entirely >>> safe to register a PMU in a hotplug callback. Due to this, we can only >>> associated hotplugged CPUs with a PMU if a matching CPU was around at >>> probe time. A similar restriction already applies to DT systems. We may >>> be able to relax this with some future work. >>> >>> I've given this some testing on a Juno platform (using SPIs). To see that IRQs >>> are correctly associated, I've tested with the following: >>> >>> $ taskset -c ${SOME_CPU_HERE} perf record \ >>> -e armv8_pmuv3_0/cpu_cycles/ \ >>> -e armv8_pmuv3_1/cpu_cycles/ \ >>> cat /proc/interrupts >>> >>> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the >>> association logic. This has also been tested in a VM using PPIs; I do not have >>> access to a host machine which itself uses PPIs. >> Booted OK and 'perf list' got on Hisilicon D03: >> >> d03-09:~ # perf list >> >> List of pre-defined events (to be used in -e): >> >> branch-misses [Hardware event] >> bus-cycles [Hardware event] >> cache-misses [Hardware event] >> cache-references [Hardware event] >> cpu-cycles OR cycles [Hardware event] >> instructions [Hardware event] >> >> alignment-faults [Software event] >> context-switches OR cs [Software event] >> cpu-clock [Software event] >> cpu-migrations OR migrations [Software event] >> dummy [Software event] >> emulation-faults [Software event] >> major-faults [Software event] >> minor-faults [Software event] >> page-faults OR faults [Software event] >> task-clock [Software event] >> >> L1-dcache-load-misses [Hardware cache event] >> L1-dcache-loads [Hardware cache event] >> L1-dcache-store-misses [Hardware cache event] >> L1-dcache-stores [Hardware cache event] >> L1-icache-load-misses [Hardware cache event] >> L1-icache-loads [Hardware cache event] >> branch-load-misses [Hardware cache event] >> branch-loads [Hardware cache event] >> dTLB-load-misses [Hardware cache event] >> iTLB-load-misses [Hardware cache event] >> >> armv8_pmuv3_0/br_mis_pred/ [Kernel PMU event] >> armv8_pmuv3_0/br_pred/ [Kernel PMU event] >> armv8_pmuv3_0/bus_access/ [Kernel PMU event] >> armv8_pmuv3_0/bus_cycles/ [Kernel PMU event] >> armv8_pmuv3_0/cid_write_retired/ [Kernel PMU event] >> armv8_pmuv3_0/cpu_cycles/ [Kernel PMU event] >> armv8_pmuv3_0/exc_return/ [Kernel PMU event] >> armv8_pmuv3_0/exc_taken/ [Kernel PMU event] >> armv8_pmuv3_0/inst_retired/ [Kernel PMU event] >> armv8_pmuv3_0/inst_spec/ [Kernel PMU event] >> armv8_pmuv3_0/l1d_cache/ [Kernel PMU event] >> armv8_pmuv3_0/l1d_cache_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l1d_cache_wb/ [Kernel PMU event] >> armv8_pmuv3_0/l1d_tlb_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l1i_cache/ [Kernel PMU event] >> armv8_pmuv3_0/l1i_cache_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l1i_tlb_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l2d_cache/ [Kernel PMU event] >> armv8_pmuv3_0/l2d_cache_refill/ [Kernel PMU event] >> armv8_pmuv3_0/l2d_cache_wb/ [Kernel PMU event] >> armv8_pmuv3_0/mem_access/ [Kernel PMU event] >> armv8_pmuv3_0/memory_error/ [Kernel PMU event] >> armv8_pmuv3_0/sw_incr/ [Kernel PMU event] >> armv8_pmuv3_0/ttbr_write_retired/ [Kernel PMU event] >> >> rNNN [Raw hardware event descriptor] >> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor] >> (see 'man perf-list' on how to encode it) >> >> mem:<addr>[/len][:access] [Hardware breakpoint] >> >> >> Try some basic perf event and it works, anything else I can try in specific? > you can try perf fuzzer Sorry, just back from my paternity leave, I will try Mark's v2 (or v3 if there is a updated one) :) Thanks Hanjun ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-10 11:04 Mark Rutland 2017-03-10 22:14 ` Jeremy Linton 2017-03-16 13:00 ` Hanjun Guo @ 2017-03-24 21:36 ` Jeremy Linton 2017-03-28 11:31 ` Mark Rutland 2 siblings, 1 reply; 23+ messages in thread From: Jeremy Linton @ 2017-03-24 21:36 UTC (permalink / raw) To: linux-arm-kernel On 03/10/2017 05:04 AM, Mark Rutland wrote: > Hi, > > This series implements ACPI support in the ARM PMU code. It borrows some code > from Jeremy's series [1], but takes a different approach to probing and > association, using the usual hotplug state machine, minimising external changes > required, and simplifying the relationship with the common arm_pmu code. > > The first few patches are preparatory cleanup/refactoring, with the latter half > of the series being specific to ACPI support. > > The series is based on my IRQ rework patches [2]. I've pushed the whole series > out to the arm/perf/acpi branch [3] of my kernel.org repo. > > Due to the innards of the hotplug callback framework, it's not entirely > safe to register a PMU in a hotplug callback. Due to this, we can only > associated hotplugged CPUs with a PMU if a matching CPU was around at > probe time. A similar restriction already applies to DT systems. We may > be able to relax this with some future work. > > I've given this some testing on a Juno platform (using SPIs). To see that IRQs > are correctly associated, I've tested with the following: > > $ taskset -c ${SOME_CPU_HERE} perf record \ > -e armv8_pmuv3_0/cpu_cycles/ \ > -e armv8_pmuv3_1/cpu_cycles/ \ > cat /proc/interrupts > > I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the > association logic. This has also been tested in a VM using PPIs; I do not have > access to a host machine which itself uses PPIs. > > Thanks, > Mark. I've been testing these on a few machines (m400 & dual socket cavium for starters) over the last few days. So far everything seems to be working fine excepting the usual set of strange messages from the perf fuzzer. Tested-by: Jeremy Linton <jlinton@arm.com> Thanks, > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/482397.html > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492891.html > [3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm/perf/acpi > > Mark Rutland (14): > drivers/perf: arm_pmu: remove pointless PMU disabling > drivers/perf: arm_pmu: define armpmu_init_fn > drivers/perf: arm_pmu: fold init into alloc > drivers/perf: arm_pmu: factor out pmu registration > drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs() > drivers/perf: arm_pmu: handle no platform_device > drivers/perf: arm_pmu: rename irq request/free functions > drivers/perf: arm_pmu: split cpu-local irq request/free > drivers/perf: arm_pmu: move irq request/free into probe > drivers/perf: arm_pmu: split out platform device probe logic > arm64: add function to get a cpu's MADT GICC table > arm64: kill acpi_set_mailbox_entry() > drivers/perf: arm_pmu: add ACPI framework > arm64: pmuv3: use arm_pmu ACPI framework > > arch/arm64/include/asm/acpi.h | 7 +- > arch/arm64/kernel/acpi_parking_protocol.c | 38 +-- > arch/arm64/kernel/perf_event.c | 26 +- > arch/arm64/kernel/smp.c | 19 +- > drivers/perf/Kconfig | 4 + > drivers/perf/Makefile | 3 +- > drivers/perf/arm_pmu.c | 383 ++++++++---------------------- > drivers/perf/arm_pmu_acpi.c | 237 ++++++++++++++++++ > drivers/perf/arm_pmu_platform.c | 235 ++++++++++++++++++ > include/linux/cpuhotplug.h | 1 + > include/linux/perf/arm_pmu.h | 22 +- > 11 files changed, 626 insertions(+), 349 deletions(-) > create mode 100644 drivers/perf/arm_pmu_acpi.c > create mode 100644 drivers/perf/arm_pmu_platform.c > ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-24 21:36 ` Jeremy Linton @ 2017-03-28 11:31 ` Mark Rutland 2017-03-28 14:41 ` Jeremy Linton 0 siblings, 1 reply; 23+ messages in thread From: Mark Rutland @ 2017-03-28 11:31 UTC (permalink / raw) To: linux-arm-kernel Hi Jeremy, On Fri, Mar 24, 2017 at 04:36:34PM -0500, Jeremy Linton wrote: > I've been testing these on a few machines (m400 & dual socket cavium > for starters) over the last few days. So far everything seems to be > working fine excepting the usual set of strange messages from the > perf fuzzer. > > Tested-by: Jeremy Linton <jlinton@arm.com> Thanks for giving this a go, especially with the fuzzer! Just to check, should that email be jeremy.linton at arm.com, or is that an alias that also works? I've added it as-is for the moment. Thanks, Mark. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 00/14] arm_pmu: ACPI support 2017-03-28 11:31 ` Mark Rutland @ 2017-03-28 14:41 ` Jeremy Linton 0 siblings, 0 replies; 23+ messages in thread From: Jeremy Linton @ 2017-03-28 14:41 UTC (permalink / raw) To: linux-arm-kernel On 03/28/2017 06:31 AM, Mark Rutland wrote: > Hi Jeremy, > > On Fri, Mar 24, 2017 at 04:36:34PM -0500, Jeremy Linton wrote: >> I've been testing these on a few machines (m400 & dual socket cavium >> for starters) over the last few days. So far everything seems to be >> working fine excepting the usual set of strange messages from the >> perf fuzzer. >> >> Tested-by: Jeremy Linton <jlinton@arm.com> > > Thanks for giving this a go, especially with the fuzzer! > > Just to check, should that email be jeremy.linton at arm.com, or is that an > alias that also works? I've added it as-is for the moment. Yes, my fingers tend to out type my brain on a regular basis, particularly when context switching between things. jeremy.linton at arm.com is correct. Thanks, ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2017-04-11 9:32 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-17 2:11 [PATCH 00/14] arm_pmu: ACPI support Itaru Kitayama 2017-03-23 10:54 ` Mark Rutland 2017-03-25 3:18 ` Itaru Kitayama -- strict thread matches above, loose matches on Subject: below -- 2017-03-10 11:04 Mark Rutland 2017-03-10 22:14 ` Jeremy Linton 2017-03-14 11:49 ` Mark Rutland 2017-03-14 18:47 ` Mark Rutland 2017-03-14 22:06 ` Agustin Vega-Frias 2017-03-15 2:49 ` Hanjun Guo 2017-03-22 12:19 ` Lorenzo Pieralisi 2017-03-22 14:06 ` Agustin Vega-Frias 2017-03-22 23:23 ` Hanjun Guo 2017-03-15 15:34 ` Mark Rutland 2017-03-16 13:00 ` Hanjun Guo 2017-03-20 18:11 ` Ganapatrao Kulkarni 2017-03-22 9:16 ` Ganapatrao Kulkarni 2017-03-22 15:59 ` Mark Rutland 2017-04-03 10:41 ` Ganapatrao Kulkarni 2017-04-03 11:12 ` Mark Rutland 2017-04-11 9:32 ` Hanjun Guo 2017-03-24 21:36 ` Jeremy Linton 2017-03-28 11:31 ` Mark Rutland 2017-03-28 14:41 ` Jeremy Linton
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.