Discussion:
[PATCH] s390: Add support for z13
(too old to reply)
Andreas Arnez
2016-05-11 14:15:57 UTC
Permalink
Raw Message
So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.

Signed-off-by: Andreas Arnez <***@linux.vnet.ibm.com>
---
events/Makefile.am | 3 ++-
libop/op_cpu_type.c | 3 +++
libop/op_cpu_type.h | 1 +
libop/op_events.c | 1 +
utils/ophelp.c | 1 +
5 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/events/Makefile.am b/events/Makefile.am
index 677b05f..29d4b5f 100644
--- a/events/Makefile.am
+++ b/events/Makefile.am
@@ -81,7 +81,8 @@ event_files = \
tile/tilegx/events tile/tilegx/unit_masks \
s390/z10/events s390/z10/unit_masks \
s390/z196/events s390/z196/unit_masks \
- s390/zEC12/events s390/zEC12/unit_masks
+ s390/zEC12/events s390/zEC12/unit_masks \
+ s390/z13/events s390/z13/unit_masks

install-data-local:
for i in ${event_files} ; do \
diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c
index 7bdde53..e70e4f6 100644
--- a/libop/op_cpu_type.c
+++ b/libop/op_cpu_type.c
@@ -123,6 +123,7 @@ static struct cpu_descr const cpu_descrs[MAX_CPU_TYPE] = {
{ "ARM Cortex-A53", "arm/armv8-ca53", CPU_ARM_V8_CA53, 6},
{ "Intel Skylake microarchitecture", "i386/skylake", CPU_SKYLAKE, 4 },
{ "Intel Goldmont microarchitecture", "i386/goldmont", CPU_GOLDMONT, 4 },
+ { "IBM z13", "s390/z13", CPU_S390_Z13, 1 },
};

static size_t const nr_cpu_descrs = sizeof(cpu_descrs) / sizeof(struct cpu_descr);
@@ -680,6 +681,8 @@ static op_cpu _get_s390_cpu_type(void)
case 2827:
case 2828:
return CPU_S390_ZEC12;
+ case 2964:
+ return CPU_S390_Z13;
}
return CPU_NO_GOOD;
}
diff --git a/libop/op_cpu_type.h b/libop/op_cpu_type.h
index 98289c5..4f896a0 100644
--- a/libop/op_cpu_type.h
+++ b/libop/op_cpu_type.h
@@ -103,6 +103,7 @@ typedef enum {
CPU_ARM_V8_CA53, /* ARM Cortex-A53 */
CPU_SKYLAKE, /** < Intel Skylake microarchitecture */
CPU_GOLDMONT, /** < Intel Goldmont microarchitecture */
+ CPU_S390_Z13, /** < IBM z13 */
MAX_CPU_TYPE
} op_cpu;

diff --git a/libop/op_events.c b/libop/op_events.c
index cdd0409..ea6ced3 100644
--- a/libop/op_events.c
+++ b/libop/op_events.c
@@ -1307,6 +1307,7 @@ void op_default_event(op_cpu cpu_type, struct op_default_event_descr * descr)
case CPU_S390_Z10:
case CPU_S390_Z196:
case CPU_S390_ZEC12:
+ case CPU_S390_Z13:
descr->name = "CPU_CYCLES";
descr->count = 4127518;
break;
diff --git a/utils/ophelp.c b/utils/ophelp.c
index 5821593..3cb1c08 100644
--- a/utils/ophelp.c
+++ b/utils/ophelp.c
@@ -779,6 +779,7 @@ int main(int argc, char const * argv[])
case CPU_S390_Z10:
case CPU_S390_Z196:
case CPU_S390_ZEC12:
+ case CPU_S390_Z13:
event_doc = "IBM System z CPU Measurement Facility\n"
"http://www-01.ibm.com/support/docview.wss"
"?uid=isg26fcd1cc32246f4c8852574ce0044734a\n";
--
2.3.0
Andreas Arnez
2016-05-23 14:51:04 UTC
Permalink
Raw Message
Post by Andreas Arnez
So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.
---
events/Makefile.am | 3 ++-
libop/op_cpu_type.c | 3 +++
libop/op_cpu_type.h | 1 +
libop/op_events.c | 1 +
utils/ophelp.c | 1 +
5 files changed, 8 insertions(+), 1 deletion(-)
Oops, that patch lacked the files in the new directory
"events/s390/z13". Corrected version below. Is this OK?

-- >8 --
Subject: [PATCH] s390: Add support for z13

So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.

Signed-off-by: Andreas Arnez <***@linux.vnet.ibm.com>
---
events/Makefile.am | 3 ++-
events/s390/z13/events | 8 ++++++++
events/s390/z13/unit_masks | 7 +++++++
libop/op_cpu_type.c | 3 +++
libop/op_cpu_type.h | 1 +
libop/op_events.c | 1 +
utils/ophelp.c | 1 +
7 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 events/s390/z13/events
create mode 100644 events/s390/z13/unit_masks

diff --git a/events/Makefile.am b/events/Makefile.am
index 677b05f..29d4b5f 100644
--- a/events/Makefile.am
+++ b/events/Makefile.am
@@ -81,7 +81,8 @@ event_files = \
tile/tilegx/events tile/tilegx/unit_masks \
s390/z10/events s390/z10/unit_masks \
s390/z196/events s390/z196/unit_masks \
- s390/zEC12/events s390/zEC12/unit_masks
+ s390/zEC12/events s390/zEC12/unit_masks \
+ s390/z13/events s390/z13/unit_masks

install-data-local:
for i in ${event_files} ; do \
diff --git a/events/s390/z13/events b/events/s390/z13/events
new file mode 100644
index 0000000..313f5b0
--- /dev/null
+++ b/events/s390/z13/events
@@ -0,0 +1,8 @@
+# Copyright OProfile authors
+# Copyright (c) International Business Machines, 2016.
+# Contributed by Andreas Arnez <***@linux.vnet.ibm.com>.
+#
+# IBM Enterprise z13 events for operf/ocount
+#
+event:0x00 counters:0 um:zero minimum:19264 name:CPU_CYCLES : Processor cycles
+event:0x01 counters:0 um:zero minimum:19264 name:INSTRUCTIONS : Instructions completed
diff --git a/events/s390/z13/unit_masks b/events/s390/z13/unit_masks
new file mode 100644
index 0000000..4cf2842
--- /dev/null
+++ b/events/s390/z13/unit_masks
@@ -0,0 +1,7 @@
+# Copyright OProfile authors
+# Copyright (c) International Business Machines, 2016.
+# Contributed by Andreas Arnez <***@linux.vnet.ibm.com>.
+#
+# S/390 Basic Mode Hardware Sampling unit masks
+#
+include:s390/z10
diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c
index 7bdde53..e70e4f6 100644
--- a/libop/op_cpu_type.c
+++ b/libop/op_cpu_type.c
@@ -123,6 +123,7 @@ static struct cpu_descr const cpu_descrs[MAX_CPU_TYPE] = {
{ "ARM Cortex-A53", "arm/armv8-ca53", CPU_ARM_V8_CA53, 6},
{ "Intel Skylake microarchitecture", "i386/skylake", CPU_SKYLAKE, 4 },
{ "Intel Goldmont microarchitecture", "i386/goldmont", CPU_GOLDMONT, 4 },
+ { "IBM z13", "s390/z13", CPU_S390_Z13, 1 },
};

static size_t const nr_cpu_descrs = sizeof(cpu_descrs) / sizeof(struct cpu_descr);
@@ -680,6 +681,8 @@ static op_cpu _get_s390_cpu_type(void)
case 2827:
case 2828:
return CPU_S390_ZEC12;
+ case 2964:
+ return CPU_S390_Z13;
}
return CPU_NO_GOOD;
}
diff --git a/libop/op_cpu_type.h b/libop/op_cpu_type.h
index 98289c5..4f896a0 100644
--- a/libop/op_cpu_type.h
+++ b/libop/op_cpu_type.h
@@ -103,6 +103,7 @@ typedef enum {
CPU_ARM_V8_CA53, /* ARM Cortex-A53 */
CPU_SKYLAKE, /** < Intel Skylake microarchitecture */
CPU_GOLDMONT, /** < Intel Goldmont microarchitecture */
+ CPU_S390_Z13, /** < IBM z13 */
MAX_CPU_TYPE
} op_cpu;

diff --git a/libop/op_events.c b/libop/op_events.c
index cdd0409..ea6ced3 100644
--- a/libop/op_events.c
+++ b/libop/op_events.c
@@ -1307,6 +1307,7 @@ void op_default_event(op_cpu cpu_type, struct op_default_event_descr * descr)
case CPU_S390_Z10:
case CPU_S390_Z196:
case CPU_S390_ZEC12:
+ case CPU_S390_Z13:
descr->name = "CPU_CYCLES";
descr->count = 4127518;
break;
diff --git a/utils/ophelp.c b/utils/ophelp.c
index 5821593..3cb1c08 100644
--- a/utils/ophelp.c
+++ b/utils/ophelp.c
@@ -779,6 +779,7 @@ int main(int argc, char const * argv[])
case CPU_S390_Z10:
case CPU_S390_Z196:
case CPU_S390_ZEC12:
+ case CPU_S390_Z13:
event_doc = "IBM System z CPU Measurement Facility\n"
"http://www-01.ibm.com/support/docview.wss"
"?uid=isg26fcd1cc32246f4c8852574ce0044734a\n";
--
2.3.0
Andreas Arnez
2016-10-04 11:54:49 UTC
Permalink
Raw Message
Still haven't received any response for this patch... Is this OK?

--
Andreas
Post by Andreas Arnez
Post by Andreas Arnez
So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.
---
events/Makefile.am | 3 ++-
libop/op_cpu_type.c | 3 +++
libop/op_cpu_type.h | 1 +
libop/op_events.c | 1 +
utils/ophelp.c | 1 +
5 files changed, 8 insertions(+), 1 deletion(-)
Oops, that patch lacked the files in the new directory
"events/s390/z13". Corrected version below. Is this OK?
-- >8 --
Subject: [PATCH] s390: Add support for z13
So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.
---
events/Makefile.am | 3 ++-
events/s390/z13/events | 8 ++++++++
events/s390/z13/unit_masks | 7 +++++++
libop/op_cpu_type.c | 3 +++
libop/op_cpu_type.h | 1 +
libop/op_events.c | 1 +
utils/ophelp.c | 1 +
7 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 events/s390/z13/events
create mode 100644 events/s390/z13/unit_masks
diff --git a/events/Makefile.am b/events/Makefile.am
index 677b05f..29d4b5f 100644
--- a/events/Makefile.am
+++ b/events/Makefile.am
@@ -81,7 +81,8 @@ event_files = \
tile/tilegx/events tile/tilegx/unit_masks \
s390/z10/events s390/z10/unit_masks \
s390/z196/events s390/z196/unit_masks \
- s390/zEC12/events s390/zEC12/unit_masks
+ s390/zEC12/events s390/zEC12/unit_masks \
+ s390/z13/events s390/z13/unit_masks
for i in ${event_files} ; do \
diff --git a/events/s390/z13/events b/events/s390/z13/events
new file mode 100644
index 0000000..313f5b0
--- /dev/null
+++ b/events/s390/z13/events
@@ -0,0 +1,8 @@
+# Copyright OProfile authors
+# Copyright (c) International Business Machines, 2016.
+#
+# IBM Enterprise z13 events for operf/ocount
+#
+event:0x00 counters:0 um:zero minimum:19264 name:CPU_CYCLES : Processor cycles
+event:0x01 counters:0 um:zero minimum:19264 name:INSTRUCTIONS : Instructions completed
diff --git a/events/s390/z13/unit_masks b/events/s390/z13/unit_masks
new file mode 100644
index 0000000..4cf2842
--- /dev/null
+++ b/events/s390/z13/unit_masks
@@ -0,0 +1,7 @@
+# Copyright OProfile authors
+# Copyright (c) International Business Machines, 2016.
+#
+# S/390 Basic Mode Hardware Sampling unit masks
+#
+include:s390/z10
diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c
index 7bdde53..e70e4f6 100644
--- a/libop/op_cpu_type.c
+++ b/libop/op_cpu_type.c
@@ -123,6 +123,7 @@ static struct cpu_descr const cpu_descrs[MAX_CPU_TYPE] = {
{ "ARM Cortex-A53", "arm/armv8-ca53", CPU_ARM_V8_CA53, 6},
{ "Intel Skylake microarchitecture", "i386/skylake", CPU_SKYLAKE, 4 },
{ "Intel Goldmont microarchitecture", "i386/goldmont", CPU_GOLDMONT, 4 },
+ { "IBM z13", "s390/z13", CPU_S390_Z13, 1 },
};
static size_t const nr_cpu_descrs = sizeof(cpu_descrs) / sizeof(struct cpu_descr);
@@ -680,6 +681,8 @@ static op_cpu _get_s390_cpu_type(void)
return CPU_S390_ZEC12;
+ return CPU_S390_Z13;
}
return CPU_NO_GOOD;
}
diff --git a/libop/op_cpu_type.h b/libop/op_cpu_type.h
index 98289c5..4f896a0 100644
--- a/libop/op_cpu_type.h
+++ b/libop/op_cpu_type.h
@@ -103,6 +103,7 @@ typedef enum {
CPU_ARM_V8_CA53, /* ARM Cortex-A53 */
CPU_SKYLAKE, /** < Intel Skylake microarchitecture */
CPU_GOLDMONT, /** < Intel Goldmont microarchitecture */
+ CPU_S390_Z13, /** < IBM z13 */
MAX_CPU_TYPE
} op_cpu;
diff --git a/libop/op_events.c b/libop/op_events.c
index cdd0409..ea6ced3 100644
--- a/libop/op_events.c
+++ b/libop/op_events.c
@@ -1307,6 +1307,7 @@ void op_default_event(op_cpu cpu_type, struct op_default_event_descr * descr)
descr->name = "CPU_CYCLES";
descr->count = 4127518;
break;
diff --git a/utils/ophelp.c b/utils/ophelp.c
index 5821593..3cb1c08 100644
--- a/utils/ophelp.c
+++ b/utils/ophelp.c
@@ -779,6 +779,7 @@ int main(int argc, char const * argv[])
event_doc = "IBM System z CPU Measurement Facility\n"
"http://www-01.ibm.com/support/docview.wss"
"?uid=isg26fcd1cc32246f4c8852574ce0044734a\n";
William Cohen
2016-10-04 15:32:03 UTC
Permalink
Raw Message
Post by Andreas Arnez
So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.
Hi,

The patch is missing the events/z13/events and events/z13/unit_masks files. Please revise the patch to add those files and resend the patch.
The rest of the patch look reasonable.

-Will
Post by Andreas Arnez
---
events/Makefile.am | 3 ++-
libop/op_cpu_type.c | 3 +++
libop/op_cpu_type.h | 1 +
libop/op_events.c | 1 +
utils/ophelp.c | 1 +
5 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/events/Makefile.am b/events/Makefile.am
index 677b05f..29d4b5f 100644
--- a/events/Makefile.am
+++ b/events/Makefile.am
@@ -81,7 +81,8 @@ event_files = \
tile/tilegx/events tile/tilegx/unit_masks \
s390/z10/events s390/z10/unit_masks \
s390/z196/events s390/z196/unit_masks \
- s390/zEC12/events s390/zEC12/unit_masks
+ s390/zEC12/events s390/zEC12/unit_masks \
+ s390/z13/events s390/z13/unit_masks
for i in ${event_files} ; do \
diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c
index 7bdde53..e70e4f6 100644
--- a/libop/op_cpu_type.c
+++ b/libop/op_cpu_type.c
@@ -123,6 +123,7 @@ static struct cpu_descr const cpu_descrs[MAX_CPU_TYPE] = {
{ "ARM Cortex-A53", "arm/armv8-ca53", CPU_ARM_V8_CA53, 6},
{ "Intel Skylake microarchitecture", "i386/skylake", CPU_SKYLAKE, 4 },
{ "Intel Goldmont microarchitecture", "i386/goldmont", CPU_GOLDMONT, 4 },
+ { "IBM z13", "s390/z13", CPU_S390_Z13, 1 },
};
static size_t const nr_cpu_descrs = sizeof(cpu_descrs) / sizeof(struct cpu_descr);
@@ -680,6 +681,8 @@ static op_cpu _get_s390_cpu_type(void)
return CPU_S390_ZEC12;
+ return CPU_S390_Z13;
}
return CPU_NO_GOOD;
}
diff --git a/libop/op_cpu_type.h b/libop/op_cpu_type.h
index 98289c5..4f896a0 100644
--- a/libop/op_cpu_type.h
+++ b/libop/op_cpu_type.h
@@ -103,6 +103,7 @@ typedef enum {
CPU_ARM_V8_CA53, /* ARM Cortex-A53 */
CPU_SKYLAKE, /** < Intel Skylake microarchitecture */
CPU_GOLDMONT, /** < Intel Goldmont microarchitecture */
+ CPU_S390_Z13, /** < IBM z13 */
MAX_CPU_TYPE
} op_cpu;
diff --git a/libop/op_events.c b/libop/op_events.c
index cdd0409..ea6ced3 100644
--- a/libop/op_events.c
+++ b/libop/op_events.c
@@ -1307,6 +1307,7 @@ void op_default_event(op_cpu cpu_type, struct op_default_event_descr * descr)
descr->name = "CPU_CYCLES";
descr->count = 4127518;
break;
diff --git a/utils/ophelp.c b/utils/ophelp.c
index 5821593..3cb1c08 100644
--- a/utils/ophelp.c
+++ b/utils/ophelp.c
@@ -779,6 +779,7 @@ int main(int argc, char const * argv[])
event_doc = "IBM System z CPU Measurement Facility\n"
"http://www-01.ibm.com/support/docview.wss"
"?uid=isg26fcd1cc32246f4c8852574ce0044734a\n";
Andreas Arnez
2016-10-04 15:42:46 UTC
Permalink
Raw Message
Post by William Cohen
Post by Andreas Arnez
So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.
Hi,
The patch is missing the events/z13/events and events/z13/unit_masks
files. Please revise the patch to add those files and resend the
patch. The rest of the patch look reasonable.
It seems that you looked at the first version of the patch. The second
version already includes the missing files:

http://marc.info/?l=oprofile-list&m=146401512127213&q=raw

Thanks,
Andreas
William Cohen
2016-10-04 15:58:23 UTC
Permalink
Raw Message
Post by Andreas Arnez
Post by William Cohen
Post by Andreas Arnez
So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.
Hi,
The patch is missing the events/z13/events and events/z13/unit_masks
files. Please revise the patch to add those files and resend the
patch. The rest of the patch look reasonable.
It seems that you looked at the first version of the patch. The second
http://marc.info/?l=oprofile-list&m=146401512127213&q=raw
Thanks,
Andreas
Hi Andreas,

You are right. Sorry, I saved and looked at the wrong patch on the thread.

The patch looks fines so it has been applied and pushed to the upstream oprofile git repository.

Thanks for the patch.

-Will
Michael Petlan
2016-10-04 21:01:56 UTC
Permalink
Raw Message
Post by William Cohen
Post by Andreas Arnez
Post by William Cohen
Post by Andreas Arnez
So far oprofile supported z Systems (s390) machines up to zEC12. This
adds support for z13 as well.
Hi,
The patch is missing the events/z13/events and events/z13/unit_masks
files. Please revise the patch to add those files and resend the
patch. The rest of the patch look reasonable.
It seems that you looked at the first version of the patch. The second
http://marc.info/?l=oprofile-list&m=146401512127213&q=raw
Thanks,
Andreas
Hi Andreas,

have you or anyone tested this patch and/or s390 oprofile support
in general? I'd love to know more about the results or at least,
if there any, what has been tested and what not + whether there
are any known issues regarding to HW sampling on s390.

Thank you very much,
Michael
Post by William Cohen
Hi Andreas,
You are right. Sorry, I saved and looked at the wrong patch on the thread.
The patch looks fines so it has been applied and pushed to the upstream oprofile git repository.
Thanks for the patch.
-Will
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
oprofile-list mailing list
https://lists.sourceforge.net/lists/listinfo/oprofile-list
Andreas Arnez
2016-10-05 18:23:04 UTC
Permalink
Raw Message
Post by William Cohen
Hi Andreas,
have you or anyone tested this patch and/or s390 oprofile support
in general? I'd love to know more about the results or at least,
if there any, what has been tested and what not + whether there
are any known issues regarding to HW sampling on s390.
IIRC, I just performed a quick smoke test before submitting this patch;
and oprofile didn't crash. Other than that, I don't really know what
works and what doesn't.

Some people mentioned various issues with oprofile on s390, depending on
kernel version and environment. Since I'm currently more focused on
other projects, I haven't investigated them. Here are some
(unconfirmed) examples:

* The --help/--usage options of operf and ocount behave strangely.
E.g., they attempt perf_open and just emit a cryptic error message if
that fails. And upon success they still yield exit code 1.

* operf is showing a warning message:

Kernel profiling is not possible with current system config.
Set /proc/sys/kernel/kptr_restrict to 0 to collect kernel samples.

* Without the --system-wide option, operf generates all-zero statistics.

--
Andreas
Michael Petlan
2016-10-12 14:01:11 UTC
Permalink
Raw Message
Post by Andreas Arnez
Post by William Cohen
Hi Andreas,
have you or anyone tested this patch and/or s390 oprofile support
in general? I'd love to know more about the results or at least,
if there any, what has been tested and what not + whether there
are any known issues regarding to HW sampling on s390.
IIRC, I just performed a quick smoke test before submitting this patch;
and oprofile didn't crash. Other than that, I don't really know what
works and what doesn't.
Could you please try it with setting /proc/sys/kernel/kptr_restrict to '0'
and /proc/sys/kernel/perf_event_paranoid to '-1', being logged as root user?

`ophelp -r`
--> should detect the machine, print "IBM z13"

`ophelp -d`
--> should print default event "CPU_CYCLES"

`ocount ls`
--> should return some non-zero value for event CPU_CYCLES

`ocount -e INSTRUCTIONS ls`
--> should use INSTRUCTIONS and return a non-zero value too

Please try out also the --system-wide mode as root.

If the above commands work, at least the basic z13 support can be verified.
Post by Andreas Arnez
Some people mentioned various issues with oprofile on s390, depending on
kernel version and environment. Since I'm currently more focused on
other projects, I haven't investigated them. Here are some
* The --help/--usage options of operf and ocount behave strangely.
E.g., they attempt perf_open and just emit a cryptic error message if
that fails. And upon success they still yield exit code 1.
Maybe if /proc/sys/kernel/perf_event_paranoid is '2' and the user is not
root, this might happen.
Post by Andreas Arnez
Kernel profiling is not possible with current system config.
Set /proc/sys/kernel/kptr_restrict to 0 to collect kernel samples.
Is kptr_restrict set to '0'?
Post by Andreas Arnez
* Without the --system-wide option, operf generates all-zero statistics.
Does `ocount` do the same? If yes, the event counting probably does not
work as expected.


Thanks!
Michael
Post by Andreas Arnez
--
Andreas
William Cohen
2016-10-12 20:27:46 UTC
Permalink
Raw Message
Post by Michael Petlan
Post by Andreas Arnez
Post by William Cohen
Hi Andreas,
have you or anyone tested this patch and/or s390 oprofile support
in general? I'd love to know more about the results or at least,
if there any, what has been tested and what not + whether there
are any known issues regarding to HW sampling on s390.
IIRC, I just performed a quick smoke test before submitting this patch;
and oprofile didn't crash. Other than that, I don't really know what
works and what doesn't.
Hi Andreas and Andreas,

Is there support for IBM z13 perf counters in the upstream linux kernel? I didn't see perf support for IBM z13 in the mainline kernel git repository.

There is a difference between the kernel and oprofile is the s390 identification. The kernel is using hex numbers such as 0x2817 and 0x2818 for Z196 identification (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kernel/perf_cpum_cf_events.c#n303), but oprofile is reading the numbers as decimal for idenfication (https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/libop/op_cpu_type.c). oprofile should also be using hex numbers like the kernel.

-Will
Post by Michael Petlan
Could you please try it with setting /proc/sys/kernel/kptr_restrict to '0'
and /proc/sys/kernel/perf_event_paranoid to '-1', being logged as root user?
`ophelp -r`
--> should detect the machine, print "IBM z13"
`ophelp -d`
--> should print default event "CPU_CYCLES"
`ocount ls`
--> should return some non-zero value for event CPU_CYCLES
`ocount -e INSTRUCTIONS ls`
--> should use INSTRUCTIONS and return a non-zero value too
Please try out also the --system-wide mode as root.
If the above commands work, at least the basic z13 support can be verified.
Post by Andreas Arnez
Some people mentioned various issues with oprofile on s390, depending on
kernel version and environment. Since I'm currently more focused on
other projects, I haven't investigated them. Here are some
* The --help/--usage options of operf and ocount behave strangely.
E.g., they attempt perf_open and just emit a cryptic error message if
that fails. And upon success they still yield exit code 1.
Maybe if /proc/sys/kernel/perf_event_paranoid is '2' and the user is not
root, this might happen.
Post by Andreas Arnez
Kernel profiling is not possible with current system config.
Set /proc/sys/kernel/kptr_restrict to 0 to collect kernel samples.
Is kptr_restrict set to '0'?
Post by Andreas Arnez
* Without the --system-wide option, operf generates all-zero statistics.
Does `ocount` do the same? If yes, the event counting probably does not
work as expected.
Thanks!
Michael
Post by Andreas Arnez
--
Andreas
Michael Petlan
2016-10-13 12:42:01 UTC
Permalink
Raw Message
Post by William Cohen
Post by Andreas Arnez
IIRC, I just performed a quick smoke test before submitting this patch;
and oprofile didn't crash. Other than that, I don't really know what
works and what doesn't.
Hi Andreas and Andreas,
Is there support for IBM z13 perf counters in the upstream linux kernel? I didn't see perf support for IBM z13 in the mainline kernel git repository.
There is a difference between the kernel and oprofile is the s390 identification. The kernel is using hex numbers such as 0x2817 and 0x2818 for Z196 identification (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kernel/perf_cpum_cf_events.c#n303), but oprofile is reading the numbers as decimal for idenfication (https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/libop/op_cpu_type.c). oprofile should also be using hex numbers like the kernel.
I have looked at this and although it is not ideal, it works OK in OProfile,
since it reads the numbers from string, thus it works with decimals.

I have also checked that zEC12 detection works correctly with 1.1.

Michael
Post by William Cohen
-Will
William Cohen
2016-10-13 14:15:05 UTC
Permalink
Raw Message
Post by Michael Petlan
Post by William Cohen
Post by Andreas Arnez
IIRC, I just performed a quick smoke test before submitting this patch;
and oprofile didn't crash. Other than that, I don't really know what
works and what doesn't.
Hi Andreas and Andreas,
Is there support for IBM z13 perf counters in the upstream linux kernel? I didn't see perf support for IBM z13 in the mainline kernel git repository.
There is a difference between the kernel and oprofile is the s390 identification. The kernel is using hex numbers such as 0x2817 and 0x2818 for Z196 identification (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kernel/perf_cpum_cf_events.c#n303), but oprofile is reading the numbers as decimal for idenfication (https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/libop/op_cpu_type.c). oprofile should also be using hex numbers like the kernel.
I have looked at this and although it is not ideal, it works OK in OProfile,
since it reads the numbers from string, thus it works with decimals.
I have also checked that zEC12 detection works correctly with 1.1.
Michael
Yes, the s390 processor detection in oprofile is not ideal with the kernel outputting the id in hex and the oprofile reading it in as a decimal. Good thing that none of the s390 id values have a-f in the digits. Attached is a patch that reads in the values as hex to better line up with the kernel's handling of the s390 identification. Could one of the IBM people try this patch?

-Will
Andreas Arnez
2016-10-14 18:32:27 UTC
Permalink
Raw Message
Post by William Cohen
Yes, the s390 processor detection in oprofile is not ideal with the kernel
outputting the id in hex and the oprofile reading it in as a decimal.
Good thing that none of the s390 id values have a-f in the digits.
Attached is a patch that reads in the values as hex to better line up with
the kernel's handling of the s390 identification. Could one of the IBM
people try this patch?
Sure. The patch looks good to me, and I've verified it on one of the
affected machines.

--
Andreas

Andreas Arnez
2016-10-13 16:14:51 UTC
Permalink
Raw Message
Post by William Cohen
Is there support for IBM z13 perf counters in the upstream linux
kernel? I didn't see perf support for IBM z13 in the mainline kernel
git repository.
To my understanding, there is currently no support for z13-specific
counters, but generic counters should still work. This certainly limits
the number of available counters on z13 significantly.

--
Andreas
William Cohen
2016-10-13 18:23:07 UTC
Permalink
Raw Message
Post by Andreas Arnez
Post by William Cohen
Is there support for IBM z13 perf counters in the upstream linux
kernel? I didn't see perf support for IBM z13 in the mainline kernel
git repository.
To my understanding, there is currently no support for z13-specific
counters, but generic counters should still work. This certainly limits
the number of available counters on z13 significantly.
--
Andreas
Hi Andreas,

In the past on x86_64 machine if the cpu wasn't identified the performance monitoring hardware would be not used at all. The upstream code arch/s390/kernel/perf_cpum_cf_events.c it doesn't identify the z13, but it does look like it falls back to cpumcf_pmu_event_attr array of events. However, I don't have much experience running things on IBM series machine, so want to verify that things are working on it.

-Will
Andreas Arnez
2016-10-13 16:08:37 UTC
Permalink
Raw Message
Post by Michael Petlan
Post by Andreas Arnez
Post by William Cohen
Hi Andreas,
have you or anyone tested this patch and/or s390 oprofile support
in general? I'd love to know more about the results or at least,
if there any, what has been tested and what not + whether there
are any known issues regarding to HW sampling on s390.
IIRC, I just performed a quick smoke test before submitting this patch;
and oprofile didn't crash. Other than that, I don't really know what
works and what doesn't.
Could you please try it with setting /proc/sys/kernel/kptr_restrict to '0'
and /proc/sys/kernel/perf_event_paranoid to '-1', being logged as root user?
Sure, I'll probably try this tomorrow.

[...]
Post by Michael Petlan
Post by Andreas Arnez
* The --help/--usage options of operf and ocount behave strangely.
E.g., they attempt perf_open and just emit a cryptic error message if
that fails. And upon success they still yield exit code 1.
Maybe if /proc/sys/kernel/perf_event_paranoid is '2' and the user is not
root, this might happen.
Right. The complaint is about the cryptic error message and the fact
that not even --help/--usage works in this case.

--
Andreas
Andreas Arnez
2016-10-14 18:24:10 UTC
Permalink
Raw Message
Post by Michael Petlan
Could you please try it with setting /proc/sys/kernel/kptr_restrict to '0'
and /proc/sys/kernel/perf_event_paranoid to '-1', being logged as root user?
Sure. With these settings I've tried the commands below on an IBM z13
machine.
Post by Michael Petlan
`ophelp -r`
--> should detect the machine, print "IBM z13"
$ ophelp -r
IBM z13
Post by Michael Petlan
`ophelp -d`
--> should print default event "CPU_CYCLES"
$ ophelp -d
CPU_CYCLES:4127518:0:1:1
Post by Michael Petlan
`ocount ls`
--> should return some non-zero value for event CPU_CYCLES
$ ocount ls
buffers.dia ocount.1 operf.1 opimport.1.in oprofile.html
buffers.png ocount.1.in operf.1.in op-jit-devel.html oprofile.xml
CodingStyle opannotate.1 opgprof.1 op-jit-devel.xml srcdoc
internals.html opannotate.1.in opgprof.1.in opreport.1 xsl
internals.xml oparchive.1 ophelp.1 opreport.1.in
Makefile oparchive.1.in ophelp.1.in opreport.xsd
Makefile.am op-check-perfevents.1 ophelp.xsd oprofile.1
Makefile.in op-check-perfevents.1.in opimport.1 oprofile.1.in

Events were actively counted for 638199 nanoseconds.
Event counts (actual) for /usr/bin/ls:
Event Count % time counted
CPU_CYCLES 2,663,679 100.00
Post by Michael Petlan
`ocount -e INSTRUCTIONS ls`
--> should use INSTRUCTIONS and return a non-zero value too
$ ocount -e INSTRUCTIONS ls
buffers.dia ocount.1 operf.1 opimport.1.in oprofile.html
buffers.png ocount.1.in operf.1.in op-jit-devel.html oprofile.xml
CodingStyle opannotate.1 opgprof.1 op-jit-devel.xml srcdoc
internals.html opannotate.1.in opgprof.1.in opreport.1 xsl
internals.xml oparchive.1 ophelp.1 opreport.1.in
Makefile oparchive.1.in ophelp.1.in opreport.xsd
Makefile.am op-check-perfevents.1 ophelp.xsd oprofile.1
Makefile.in op-check-perfevents.1.in opimport.1 oprofile.1.in

Events were actively counted for 659414 nanoseconds.
Event counts (actual) for /usr/bin/ls:
Event Count % time counted
INSTRUCTIONS 1,436,364 100.00
Post by Michael Petlan
Please try out also the --system-wide mode as root.
# ocount --system-wide
ocount: Press Ctl-c or 'kill -SIGINT 61412' to stop counting
^C
Events were actively counted for 1.5 seconds.
Event counts (actual) for the whole system:
Event Count % time counted
CPU_CYCLES 15,981,710 100.00
Post by Michael Petlan
If the above commands work, at least the basic z13 support can be verified.
Looks OK to me.

--
Andreas
Loading...