On 05/03/2021 16:32, Robin Murphy wrote:
In converting intel-iommu over to the common IOMMU DMA ops, it quietly
lost the functionality of its "forcedac" option. Since this is a handy
thing both for testing and for performance optimisation on certain
platforms, reimplement it under the common
to those requests in the driver
tagset. This is done with a cmpxchg to make safe any race with setting the
driver tagset request from another queue.
Signed-off-by: John Garry
---
block/blk-mq-sched.c | 2 +-
block/blk-mq-tag.c | 2 +-
block/blk-mq.c | 20 ++--
block/blk-mq.h
tagset, and it seeing
a stale IO scheduler request from the other queue after they are freed.
To stop this happening, freeze and quiesce all queues associated with the
tagset as the elevator is exited.
Signed-off-by: John Garry
---
I think that this patch is what Bart suggested:
https
.
This should not break any semantics in blk_mq_all_tag_iter(), as, since
all queues are frozen, there should be no active tags to iterate.
Signed-off-by: John Garry
---
block/blk-mq-tag.c | 5 +
block/blk-mq.c | 1 +
block/blk.h| 4
include/linux/blk-mq.h | 1 +
4
patches are really for extreme scenarios which may
never be seen in practice. As such, it could be considered to just accept
patch 1/3 now.
Differences to v2:
- Add patch 2+3/3
- Drop patch to lockout blk_mq_queue_tag_busy_iter() when exiting elevator
John Garry (3):
blk-mq: Clean up references
On 05/03/2021 10:18, Shunsuke Nakamura wrote:
The perf parser does not support event names that start with a number.
This patch adds "_" to the event name, which starts with a number.
Signed-off-by: Shunsuke Nakamura
I think that this can be folded into patch 2/3, and my reveiwed-by tag
Hi Jirka,
- struct pmu_events_map *map = perf_pmu__find_map(NULL);
+ struct pmu_events_map *map = find_cpumap();
so this is just for arm at the moment right?
Yes - but to be more accurate, arm64.
At the moment, from the archs which use pmu-events, only arm64 and nds32
have
-by: Shunsuke Nakamura
Acked-by: John Garry
---
tools/perf/util/parse-events.l | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 0b36285a9435..33f627187415 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf
Add L2 metrics.
Signed-off-by: John Garry
---
.../arch/arm64/hisilicon/hip08/metrics.json | 42 +++
1 file changed, 42 insertions(+)
diff --git a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
Add L1 metrics. Formula is as consistent as possible with standard.
Signed-off-by: John Garry
---
.../arch/arm64/hisilicon/hip08/metrics.json | 30 +++
1 file changed, 30 insertions(+)
create mode 100644
tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
diff
Use find_cpumap() to get the cpumap for the common CPU PMU, if one exists.
Signed-off-by: John Garry
---
tools/perf/util/metricgroup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 9a2a23093961
Add L3 metrics.
Signed-off-by: John Garry
---
.../arch/arm64/hisilicon/hip08/metrics.json | 161 ++
1 file changed, 161 insertions(+)
diff --git a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
, looking
for a CPU PMU, and use the cpumap there for determining supported metrics.
For heterogeneous systems (like arm big.LITTLE), supporting metrics has
potential challenges, like not all CPUs in a system not supporting a
specific metric event. So just don't support it for now.
Signed-off-by: John
s from sysfs, which arm
does not do. To get that to work, we probably need to make perf use the
pmu-events cpumap to learn about those alias events.
John Garry (5):
perf metricgroup: Support printing metrics for arm64
perf metricgroup: Support adding metrics for arm64
perf vendor events arm6
On 01/03/2021 15:48, John Garry wrote:
While max32_alloc_size indirectly tracks the largest*contiguous*
available space, one of the ideas from which it grew was to simply keep
count of the total number of free PFNs. If you're really spending
significant time determining that the tree is full
On 01/03/2021 13:20, Robin Murphy wrote:
FWIW, I'm 99% sure that what you really want is [1], but then you get
to battle against an unknown quantity of dodgy firmware instead.
Something which has not been said before is that this only happens for
strict mode.
I think that makes sense - once
Function free_cpu_cached_iovas() is not only called when a CPU is
hotplugged, so remove that part of the code comment.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index
Like the intel IOMMU driver already does, flush the per-IOVA domain
CPU rcache when a CPU goes offline - there's no point in keeping it.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 30 +-
include/linux/cpuhotplug.h | 1 +
include/linux/iova.h
The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is
offlined.
Let's move it to core code, so everyone can take advantage.
Also correct a code comment.
Based on v5.12-rc1. Tested on arm64 only.
John Garry (3):
iova: Add CPU hotplug handler to flush rcaches
iommu/vt-d
Now that the core code handles flushing per-IOVA domain CPU rcaches,
remove the handling here.
Signed-off-by: John Garry
---
drivers/iommu/intel/iommu.c | 31 ---
include/linux/cpuhotplug.h | 1 -
2 files changed, 32 deletions(-)
diff --git a/drivers/iommu/intel
On 26/02/2021 15:47, Andi Kleen wrote:
On Fri, Feb 26, 2021 at 09:08:17PM +0800, John Garry wrote:
Included for each CPU entry in the per-arch mapfile.csv file is a 'type'
field.
I don't like it because this will make the mapfile incompatible with
what download.01.org uses. We originally
d to
'core'.
So just remove it, as so far this has just caused confusion.
Signed-off-by: John Garry
diff --git a/tools/perf/pmu-events/arch/arm64/mapfile.csv
b/tools/perf/pmu-events/arch/arm64/mapfile.csv
index 0d609149b82a..4e6f934cd93d 100644
--- a/tools/perf/pmu-events/arch/arm64/mapfile.csv
+
On 25/02/2021 19:35, Jiri Olsa wrote:
On Thu, Feb 25, 2021 at 08:13:07PM +0100, Jiri Olsa wrote:
On Thu, Feb 25, 2021 at 06:39:22PM +, John Garry wrote:
Hi,
I notice that "perf test" when run without root priviledges now hangs at the
daemon test - is this expected behaviour? C
ira Jajeev
, Dmitry Safonov ,
Hans-Peter Nilsson , Ian Rogers , James
Clark , Jianlin Lv , Jin Yao
, John Garry , Kan Liang
, Kees Kook , Leo Yan
, Martin Liška , Mike Leach
, Paul Cercueil , Song Liu
, Stephane Eranian , Yang Li
, Yonatan Goldschmidt
, Arnaldo Carvalho de Melo
On 29/01/2021 12:03, Robin Murphy wrote:
On 2021-01-29 09:48, Leizhen (ThunderTown) wrote:
Currently, we are thinking about the solution to the problem. However,
because the end time of v5.11 is approaching, this patch is sent first.
However, that commit was made for a reason - how do we
On 22/02/2021 07:26, Yang Li wrote:
fixed the following coccicheck:
./drivers/scsi/scsi_transport_iscsi.c:436:60-61: WARNING opportunity for
kobj_to_dev()
./drivers/scsi/scsi_transport_iscsi.c:1128:60-61: WARNING opportunity
for kobj_to_dev()
./drivers/scsi/scsi_transport_iscsi.c:4043:61-62:
treated as errors
...
This patch fixes Wformat-overflow warnings. Add helper function to
convert NULL to "unknown".
Signed-off-by: Jianlin Lv
thanks
Reviewed-by: John Garry
---
tools/perf/builtin-script.c| 4 +++-
tools/perf/util/scripting-engines/trace-event-python.c | 3 ++-
tools/perf/util/session.c | 3 ++-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-script.c
locate that, how can we make sure it will not conflict with
the request->tag ?
Regards,
Viswas G
-Original Message-----
From: John Garry
Sent: Monday, February 1, 2021 10:46 PM
To: Viswas G - I30667 ; j...@linux.ibm.com;
martin.peter...@oracle.com; akshat...@google.com; Ruksar Devadi -
I5
Nakamura
---
FWIW,
Acked-by: John Garry
I would prefer if more knowledgeable perf reviewers also checked this...
tools/perf/util/parse-events.l | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 0b36285a9435
On 12/02/2021 09:03, Shunsuke Nakamura wrote:
Add pmu events for A64FX.
Documentation source:
https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_PMU_Events_v1.2.pdf
Signed-off-by: Shunsuke Nakamura
Reviewed-by: John Garry
On 10/02/2021 15:34, nakamura.s...@fujitsu.com wrote:
Hi, John
So my series is now on remotes/origin/tmp.perf/core in Arnaldo's acme git, so
you could resend against that.
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
Or again, put my series on perf/core and
+
On 04/01/2021 18:37, John Garry wrote:
Hi Bart,
Right, what I proposed is unrelated to the use-after-free triggered by
disabling I/O scheduling.
Regarding the races triggered by disabling I/O scheduling: can these be
fixed by quiescing all request queues associated with a tag set before
On 10/02/2021 03:24, Jianlin Lv wrote:
gcc version: 11.0.0 20210208 (experimental) (GCC)
Following build error on arm64:
...
In function ‘printf’,
inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
inlined from ‘regs__printf’ at util/session.c:1169:2:
On 09/02/2021 12:17, Leo Yan wrote:
Hi Jianlin,
On Tue, Feb 09, 2021 at 07:33:57PM +0800, Jianlin Lv wrote:
gcc version: 11.0.0 20210208 (experimental) (GCC)
Following build error on arm64:
...
In function ‘printf’,
inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
On 08/02/2021 10:58, Luo Jiaxing wrote:
When the number of online CPUs is less than 16, we found that it will fail
to allocate 32 MSI interrupts (including 16 affinity interrupts) after the
hisi_sas module is unloaded and then reloaded.
After analysis, it is found that a bug exists when the ITS
On 08/02/2021 01:53, nakamur'd a.s...@fujitsu.com wrote:
Hi, John
Apart from that, I think that we're a bit uncertain about patch 3/4
What are your concerns?
I think it's okay for perf to read a new event code with a number at the
beginning.
The impact of this fix is on {name} and later
001
From: John Garry
Date: Fri, 5 Feb 2021 09:50:54 +
Subject: [PATCH] perf test: Add parse-metric list test scenario
diff --git a/tools/perf/tests/parse-metric.c
b/tools/perf/tests/parse-metric.c
index ce7be37f0d88..0626e389354c 100644
--- a/tools/perf/tests/parse-metric.c
+++ b/tools/perf/te
On 03/02/2021 17:23, Marc Zyngier wrote:
Before:
In free path, we have:
its_irq_domain_free(nvecs = 27)
bitmap_release_region(count order = 5 == 32bits)
Current:
In free path, we have:
its_irq_domain_free(nvecs = 1) for free each 27 vecs
bitmap_release_region(count
On 03/02/2021 00:46, Jin, Yao wrote:
This should be fixed in v5.11-rc6 - please check it.
9c880c24cb0d perf metricgroup: Fix for metrics containing duration_time
Thanks,
John
Oh, I see, your patch is in Arnaldo's perf/urgent branch. Sorry about
that, I just tested Arnaldo's perf/core
://lore.kernel.org/lkml/1611835236-34696-3-git-send-email-john.ga...@huawei.com/
John Garry (1):
perf vendor events arm64: Add common and uarch event JSON
Shunsuke Nakamura (3):
perf vendor events arm64: Add common and uarch event JSON
perf vendor events arm64: Add more common and uarch events
perf
On 02/02/2021 14:48, Marc Zyngier wrote:
Not sure. I also now notice an error for the SAS PCI driver on D06
when nr_cpus < 16, which means number of MSI vectors allocated < 32,
so looks the same problem. There we try to allocate 16 + max(nr cpus,
16) MSI.
Anyway, let me have a look today
Here's my suspicion: two of the interrupts are mapped in the low-level
domain (the ITS, I'd expect in your case), but they have never been
mapped at the higher level.
On teardown, we only get rid of the 30 that were actually mapped, and
leave the last two dangling in the ITS domain, and thus the
On 01/02/2021 18:50, Marc Zyngier wrote:
Hi Marc,
Just a heads-up, by chance I noticed that I can't re-insert a specific
driver on v5.11-rc6:
[ 64.356023] hisi_dma :7b:00.0: Adding to iommu group 31
[ 64.368627] hisi_dma :7b:00.0: enabling device ( -> 0002)
[ 64.384156]
On 02/02/2021 02:24, Jin Yao wrote:
Hit a segmentation fault for DRAM_BW_Use on SKL/KBL.
# perf stat -M DRAM_BW_Use -a -- sleep 1
Segmentation fault (core dumped)
(gdb) backtrace
#0 __strcmp_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1
Just a heads-up, by chance I noticed that I can't re-insert a specific
driver on v5.11-rc6:
[ 64.356023] hisi_dma :7b:00.0: Adding to iommu group 31
[ 64.368627] hisi_dma :7b:00.0: enabling device ( -> 0002)
[ 64.384156] hisi_dma :7b:00.0: Failed to allocate MSI vectors!
[
LDD manage this itself. I
mentioned this perviously elsewhere. Do you plan to make that change?
hisi_sas and megaraid sas are examples of drivers who do this.
Thanks,
John
Regards,
Viswas G
-Original Message-
From: John Garry
Sent: Monday, February 1, 2021 4:53 PM
To: Viswas G - I30667
On 01/02/2021 11:13, Shunsuke Nakamura wrote:
Fix the lexical definition of event name so that the numbers are recognizable.
A64FX defines an event name that starts with a number.
- 0inst_commit
- 1inst_commit
- 2inst_commit
- 3inst_commit
- 4inst_commit
Signed-off-by: Shunsuke
On 01/02/2021 11:13, Shunsuke Nakamura wrote:
About the subject, include "arm64", like other commits in same arch path
about "V1.2", we use wildcard for matching MIDR, so will these JSONs
really just patch V1.2?
Add pmu events for A64FX.
Documentation source:
:
Reviewed-by: John Garry
coredd hest_disable disable_cpu_apicid=0
-----Original Message-
From: John Garry
Sent: Tuesday, January 5, 2021 4:47 PM
To: j...@linux.ibm.com; martin.peter...@oracle.com;
akshat...@google.com; Viswas G - I30667 ;
Ruksar Devadi - I52327 ;
ra...@google.com; bjashn...@google.com; vishakh..
The ARM_SMMU_V3_PMU dependency on ARM_SMMU_V3_PMU was added with the idea
that a SMMUv3 PMCG would only exist on a system with an associated SMMUv3.
However it is not the job of Kconfig to make these sorts of decisions (even
if it were true), so remove the dependency.
Signed-off-by: John Garry
umentation/arm64/eMAG-ARM-CoreImpDefined.pdf
Signed-off-by: John Garry
---
.../arch/arm64/ampere/emag/branch.json| 8 +--
.../arch/arm64/ampere/emag/bus.json | 5 +-
.../arch/arm64/ampere/emag/cache.json | 56 +--
.../arch/arm64/ampere/emag/clock.json
:
[0] https://documentation-service.arm.com/static/5fa3bd1eb209f547eebd4141?token=
Signed-off-by: John Garry
---
.../arm64/armv8-common-and-microarch.json | 248 ++
1 file changed, 248 insertions(+)
create mode 100644
tools/perf/pmu-events/arch/arm64/armv8-common
different to
standard are changed (to standard) for consistency.
Signed-off-by: John Garry
---
.../arch/arm64/arm/cortex-a76-n1/branch.json | 12 +-
.../arch/arm64/arm/cortex-a76-n1/bus.json | 19 ++-
.../arch/arm64/arm/cortex-a76-n1/cache.json | 118 ++
.../arm64/arm/cor
differences. In addition, event names are
renamed to be same as architecture reference manual, to keep commonality.
Also a minor fix is included for the Ampere eMag JSON.
Differences to v1:
- tidy some ',' misplaced
John Garry (4):
perf vendor events arm64: Fix Ampere eMag event typo
perf vendor
The "briefdescription" for event 0x35 has a typo - fix it.
Fixes: d35c595bf005 ("perf vendor events arm64: Revise core JSON events for
eMAG")
Signed-off-by: John Garry
---
tools/perf/pmu-events/arch/arm64/ampere/emag/cache.json | 2 +-
1 file changed, 1 insertion(+), 1 del
On 28/01/2021 05:30, nakamura.s...@fujitsu.com wrote:
Hi ,john
I would like to make a comment because there is excess or deficiency in comma.
There are no differences in pmu-events.c.
+{
+"PublicDescription": "Attributable Bus access",
+"EventCode": "0x19",
+
n imx8mm metrics
perf vendor events: Add JSON metrics for imx8mn DDR Perf
perf vendor events: Add JSON metrics for imx8mq DDR Perf
perf vendor events: Add JSON metrics for imx8mp DDR Perf
For the series:
Reviewed-by: John Garry
For reference, here's how /proc/ioports looks on my arm64 system with
this change:
root@ubuntu:/home/john# more /proc/ioports
0001-0001 : PCI Bus 0002:f8
0001-00010fff : PCI Bus 0002:f9
0001-00010007 : 0002:f9:00.0
0001-00010007 : serial
00010008-0001000f
umentation/arm64/eMAG-ARM-CoreImpDefined.pdf
Signed-off-by: John Garry
---
.../arch/arm64/ampere/emag/branch.json| 8 +--
.../arch/arm64/ampere/emag/bus.json | 5 +-
.../arch/arm64/ampere/emag/cache.json | 56 +--
.../arch/arm64/ampere/emag/clock.json
The "briefdescription" for event 0x35 has a typo - fix it.
Fixes: d35c595bf005 ("perf vendor events arm64: Revise core JSON events for
eMAG")
Signed-off-by: John Garry
---
tools/perf/pmu-events/arch/arm64/ampere/emag/cache.json | 2 +-
1 file changed, 1 insertion(+), 1 del
On 22/01/2021 08:37, nakamura.s...@fujitsu.com wrote:
I think that we need to the same here as the IMPDEF recommended events - add a
common JSON to reduce the duplication.
I had done work on this for current CPUs, but never got it finished. Let me
check
the status.
If you let me know the
-by: John Garry
---
drivers/scsi/hisi_sas/Kconfig | 6 ++
drivers/scsi/hisi_sas/hisi_sas_main.c | 13 +++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hisi_sas/Kconfig b/drivers/scsi/hisi_sas/Kconfig
index b8148b1733f8..4ba3a8eadb77 100644
as a kernel config option
Thanks!
John Garry (2):
scsi: hisi_sas: Remove deferred probe check in hisi_sas_v2_probe()
scsi: hisi_sas: Don't check .nr_hw_queues in hisi_sas_task_prep()
Luo Jiaxing (3):
scsi: hisi_sas: Enable debugfs support by default
scsi: hisi_sas: Flush workqueue
to ensure any resets have been completed.
Signed-off-by: Luo Jiaxing
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index e91df469e36b
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 625327e99b06..d469ffda9008 100644
--- a/drivers/scsi/hisi_sas
be removed.
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 502ad3e4f7cd..46f60fc2a069 100644
--- a/drivers/scsi/hisi_sas
by reading the rd_data.
These 32 signal datas is the status record of hardware at different time
points.
Signed-off-by: Luo Jiaxing
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas.h | 15 ++
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 251 +
2 files changed, 266
Event duration_time in a metric expression requires special handling.
Improve test coverage by including a metric whose expression includes
duration_time. The actual metric is a copied from the L1D_Cache_Fill_BW
metric on my broadwell machine.
Signed-off-by: John Garry
---
Based on acme perf
On 25/01/2021 11:53, John Garry wrote:
+ Missed reviewers for
https://lore.kernel.org/lkml/1611575600-2440-1-git-send-email-john.ga...@huawei.com/T/#u
There is much event duplication in the common and uarch events for A76
and Ampere eMag support, so factor out into a common JSON.
Since
different to
standard are changed (to standard) for consistency.
Signed-off-by: John Garry
---
.../arch/arm64/arm/cortex-a76-n1/branch.json | 12 +-
.../arch/arm64/arm/cortex-a76-n1/bus.json | 19 ++-
.../arch/arm64/arm/cortex-a76-n1/cache.json | 118 ++
.../arm64/arm/cor
:
[0] https://documentation-service.arm.com/static/5fa3bd1eb209f547eebd4141?token=
Signed-off-by: John Garry
---
.../arm64/armv8-common-and-microarch.json | 248 ++
1 file changed, 248 insertions(+)
create mode 100644
tools/perf/pmu-events/arch/arm64/armv8-common
differences. In addition, event names are
renamed to be same as architecture reference manual, to keep commonality.
Also a minor fix is included for the Ampere eMag JSON.
John Garry (4):
perf vendor events arm64: Fix Ampere eMag event typo
perf vendor events arm64: Add common and uarch event JSON
On 21/01/2021 20:31, Arnaldo Carvalho de Melo wrote:
They are not normally broken like that. Normally we test beforehand, but
these cases were missed here by me. However if you were testing them
previously, then it would be expected that you had tested them again for the
final patchset which was
On 21/01/2021 11:39, Shaokun Zhang wrote:
Hi,
在 2021/1/21 18:54, Shunsuke Nakamura 写道:
Adds L1 data cache refill prefetch, L2 data cache refill prefetch,
and DCZVA instruction events.
A silly question, Does Arm define these events? I checked Arm ARM
document(DDI0487Fc) that these event
On 21/01/2021 10:54, Shunsuke Nakamura wrote:
+ {
+"PublicDescription": "This event counts each correction to the predicted
program flow that occurs because of a misprediction from, or no prediction from, the branch
prediction resources and that relates to instructions that the branch
>
>
> Thanks for this, it should be fairly easy to add a test. Could we
do this?
I don't mind following up with that.
How about this:
>8
From 38e9d5aa07588d552378d97760b6b79f19d59bbd Mon Sep 17 00:00:00 2001
From: John Garry
Date: Thu, 21 Ja
On 20/01/2021 16:40, Ian Rogers wrote:
On Wed, Jan 20, 2021 at 8:23 AM John Garry <mailto:john.ga...@huawei.com>> wrote:
Metrics containing duration_time cause a segfault:
$./perf stat -v -M L1D_Cache_Fill_BW sleep 1
Using CPUID GenuineIntel-6-3D-4
metri
f metricgroup: Fix metrics using aliases covering
multiple PMUs")
Reported-by: Joakim Zhang
Signed-off-by: John Garry
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 2e60ee170abc..e6d3452031e5 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/
On 20/01/2021 12:56, Jiri Olsa wrote:
that's fixing the issue for me, this was crashing:
# perf stat -a -I 1000 -M L1D_Cache_Fill_BW,L2_Cache_Fill_BW
could you please send it formaly, so it can be merged?
I will do it today. But I want to make sure that the logic is correct,
so checking
On 20/01/2021 05:15, Joakim Zhang wrote:
-Original Message-
From: John Garry
Sent: 2021年1月20日 1:33
To: Joakim Zhang ; pet...@infradead.org;
mi...@redhat.com; a...@kernel.org; mark.rutl...@arm.com;
alexander.shish...@linux.intel.com; jo...@redhat.com;
namhy...@kernel.org; irog
On 19/01/2021 15:47, John Garry wrote:
On 19/01/2021 10:56, Joakim Zhang wrote:
It seems have other issue compared to 5.10 kernel after switching to
this framework, below metric can't work.
"MetricExpr": "(( imx8_ddr0@read\\-cycles@ + imx8_ddr0@write\\-cycles@
) * 4 * 4 / durati
On 19/01/2021 10:56, Joakim Zhang wrote:
It seems have other issue compared to 5.10 kernel after switching to this
framework, below metric can't work.
"MetricExpr": "(( imx8_ddr0@read\\-cycles@ + imx8_ddr0@write\\-cycles@ ) * 4 * 4 /
duration_time) / (750 * 100 * 4 * 4)"
After change to:
On 19/01/2021 10:56, Joakim Zhang wrote:
root@imx8mmevk:~# ./perf stat -a -I 1000 -M
imx8mm_ddr_read.all,imx8mm_ddr_write
.all
# time counts unit events
1.001446500
for system
PMUs")
Reported-by: Joakim Zhang
Signed-off-by: John Garry
root@imx8mmevk:~# ./perf stat -a -I 1000 -M
imx8mm_ddr_read.all,imx8mm_ddr_write
.all
# time counts unit even
is broken, in that
add_metric() @m argument should be NULL for each new metric. Fix by not
passing a holder for that, and rather make local in
metricgroup__add_metric_sys_event_iter().
Fixes: be335ec28efa ("perf metricgroup: Support adding metrics for system PMUs")
Reported-by: Joakim Zhang
On 18/01/2021 12:59, Robin Murphy wrote:
for cpu_rcaches too, and get a similar abort at runtime.
It's not specifically that we expect them (allocation failures for the
loaded magazine), rather we should make safe against it.
So could you be more specific in your concern for the cpu_rcache
On 15/01/2021 19:21, Robin Murphy wrote:
It would be good to understand why the rcache doesn't stabilize. Could be
a bug, or just need some tuning
In strict mode, if a driver does Alloc-Free-Alloc and the first alloc
misses the rcache, the second allocation hits it. The same sequence in
On 18/01/2021 10:08, Jean-Philippe Brucker wrote:
Any idea why that's happening? This fix seems ok but if we're expecting
allocation failures for the loaded magazine then we could easily get it
for cpu_rcaches too, and get a similar abort at runtime.
It's not specifically that we expect them
On 15/01/2021 17:30, Jean-Philippe Brucker wrote:
On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
A similar crash to the following could be observed if initial CPU rcache
magazine allocations fail in init_iova_rcaches():
thanks for having a look
Any idea why that's happening
On 18/01/2021 01:59, Jiaxun Yang wrote:
在 2021/1/16 上午12:58, John Garry 写道:
This is a reboot of my original series to address the problem of drivers
for legacy ISA devices accessing unmapped IO port regions on arm64
systems
and causing the system to crash.
There was another recent report
Introduce IO_SPACE_BASE, which is the base address of the IO port region.
0x1 is chosen intentionally to exclude legacy ISA IO port address
range.
Signed-off-by: John Garry
---
arch/arm64/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/io.h b
since v4:
https://lore.kernel.org/linux-pci/1560262374-67875-1-git-send-email-john.ga...@huawei.com/
- Reserve legacy ISA region
John Garry (4):
arm64: io: Introduce IO_SPACE_BASE
asm-generic/io.h: Add IO_SPACE_BASE
kernel/resource: Make ioport_resource.start configurable
logic_pio: Warn
a resource region will now fail
for architectures with set IO_SPACE_BASE above legacy ISA IO port region
(0x).
Signed-off-by: John Garry
---
kernel/resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 3ae2f56cc79d..d191c4d796c7
Add a fallback default for IO_SPACE_BASE (at 0) for when an architecture
does not define a value.
Signed-off-by: John Garry
---
include/asm-generic/io.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 9ea83d80eb6f..4d74a0c696ca
Start the PCI MMIO region at IO_SPACE_BASE, and warn on any accesses below
that address. Those accesses are also discarded.
This is only for CONFIG_INDIRECT_PIO currently, and support can be added
later for !CONFIG_INDIRECT_PIO.
Signed-off-by: John Garry
---
include/linux/logic_pio.h | 5
On 15/01/2021 16:27, Ahmed S. Darwish wrote:
Thanks!
Shall I add you r-b tag to the whole series then, or only to the ones
which directly touch libsas (#3, #12, #16, and #19)?
The whole series, if you like. But there was a nit about fitting some
code on a single line still, and I think
+ linux-scsi (see
https://lore.kernel.org/linux-iommu/1607538189-237944-4-git-send-email-john.ga...@huawei.com/)
On 17/11/2020 10:25, John Garry wrote:
This series contains a patch to solve the longterm IOVA issue which
leizhen originally tried to address at [0].
A sieved kernel log
On 21/12/2020 13:04, Jiahui Cen wrote:
On 21/12/2020 03:24, Jiahui Cen wrote:
Hi John,
On 2020/12/18 18:40, John Garry wrote:
On 18/12/2020 06:23, Jiahui Cen wrote:
Since the [start, end) is a half-open interval, a range with the end equal
to the start of another range should
101 - 200 of 3187 matches
Mail list logo
