From: Will D. <wil...@ar...> - 2012-06-15 10:08:05
|
Hello, Following on from Maynard's post advertising the perf-events branch: http://sourceforge.net/mailarchive/message.php?msg_id=29390076 These couple of patches add support for ARM cores to operf. There are a number of recent ARMv7 cores that I will support in additional patches (I just need to sit down and write the events files) when this has settled down. I'm posting this as an RFC due to the following hurdles: 1.) I've probably broken ppc64 with my /proc/cpuinfo parser changes but I don't have a relevant machine on which to test the patch. 2.) Cross-compiling for ARM doesn't work and I see the following error during configure: checking kernel version supports perf_events... This kernel has perf_events support checking for "/usr/include/linux/perf_event.h"... configure: error: cannot check for file existence when cross compiling perhaps we should have a --with-perf-events option or something similar? 3.) operf requests exclude_idle=1 in the perf_event_attr passed to the kernel. ARM cores do not support this mode exclusion and requesting it will give you -EPERM (which is the wrong error code -- I'll fix this in the kernel...). All feedback welcome, Will Will Deacon (2): Factor out ppc64 /proc/cpuinfo parsing Add ARM cpu type parsing using /proc/cpuinfo libop/op_cpu_type.c | 132 +++++++++++++++++++++++++++++++++++++++----------- 1 files changed, 103 insertions(+), 29 deletions(-) -- 1.7.4.1 |
From: Will D. <wil...@ar...> - 2012-06-15 10:08:01
|
The /proc/cpuinfo parsing code used by ppc64 to identify the current CPU type is useful for other architectures that don't have a userspace cpuid instruction (for example, ARM). This patch factors out the /proc/cpuinfo reading code in preparation for ARM support. Signed-off-by: Will Deacon <wil...@ar...> --- libop/op_cpu_type.c | 75 +++++++++++++++++++++++++++++++------------------- 1 files changed, 46 insertions(+), 29 deletions(-) diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c index 64a9830..34b20e7 100644 --- a/libop/op_cpu_type.c +++ b/libop/op_cpu_type.c @@ -105,44 +105,61 @@ static struct cpu_descr const cpu_descrs[MAX_CPU_TYPE] = { static size_t const nr_cpu_descrs = sizeof(cpu_descrs) / sizeof(struct cpu_descr); -static op_cpu _get_ppc64_cpu_type(void) +static char * _get_cpuinfo_cpu_type(char * buf, int len, const char * prefix) { - char line[100]; - op_cpu cpu_type = CPU_NO_GOOD; - FILE * fp; - fp = fopen("/proc/cpuinfo", "r"); + char * ret = NULL; + int prefix_len = strlen(prefix); + FILE * fp = fopen("/proc/cpuinfo", "r"); + if (!fp) { perror("Unable to open /proc/cpuinfo\n"); - return cpu_type; + return ret; } - memset(line, 0, 100); - while (cpu_type == CPU_NO_GOOD) { - if (fgets(line, sizeof(line), fp) == NULL) { + + memset(buf, 0, len); + + while (!ret) { + if (fgets(buf, len, fp) == NULL) { fprintf(stderr, "Did not find processor type in /proc/cpuinfo.\n"); - goto out; + break; } - if (!strncmp(line, "cpu", 3)) { - char cpu_name[64]; - char *cpu = line + 3; - while (*cpu && isspace(*cpu)) - ++cpu; - if (sscanf(cpu, ":%s ", cpu_name) == 1) { - int i; - char cpu_type_str[64], cpu_name_lowercase[64]; - size_t len = strlen(cpu_name); - for (i = 0; i < (int)len ; i++) - cpu_name_lowercase[i] = tolower(cpu_name[i]); - - cpu_type_str[0] = '\0'; - strcat(cpu_type_str, "ppc64/"); - strncat(cpu_type_str, cpu_name_lowercase, len); - cpu_type = op_get_cpu_number(cpu_type_str); - } + if (!strncmp(buf, prefix, prefix_len)) { + ret = buf + prefix_len; + /* Strip leading whitespace and ':' delimiter */ + while (*ret && (*ret == ':' || isspace(*ret))) + ++ret; + buf = ret; + /* Scan ahead to the end of the token */ + while (*buf && !isspace(*buf)) + ++buf; + /* Trim trailing whitespace */ + *buf = '\0'; + break; } } - out: + fclose(fp); - return cpu_type; + return ret; +} + +static op_cpu _get_ppc64_cpu_type(void) +{ + int i; + size_t len; + char line[100], cpu_type_str[64], cpu_name_lowercase[64], * cpu_name; + + cpu_name = _get_cpuinfo_cpu_type(line, 100, "cpu"); + if (!cpu_name) + return CPU_NO_GOOD; + + len = strlen(cpu_name); + for (i = 0; i < (int)len ; i++) + cpu_name_lowercase[i] = tolower(cpu_name[i]); + + cpu_type_str[0] = '\0'; + strcat(cpu_type_str, "ppc64/"); + strncat(cpu_type_str, cpu_name_lowercase, len); + return op_get_cpu_number(cpu_type_str); } static op_cpu _get_x86_64_cpu_type(void) -- 1.7.4.1 |
From: Maynard J. <may...@us...> - 2012-06-15 18:53:05
|
On 06/15/2012 05:07 AM, Will Deacon wrote: > The /proc/cpuinfo parsing code used by ppc64 to identify the current > CPU type is useful for other architectures that don't have a userspace > cpuid instruction (for example, ARM). > > This patch factors out the /proc/cpuinfo reading code in preparation > for ARM support. > > Signed-off-by: Will Deacon <wil...@ar...> > --- > libop/op_cpu_type.c | 75 +++++++++++++++++++++++++++++++------------------- > 1 files changed, 46 insertions(+), 29 deletions(-) > Patch committed. Thanks. -Maynard [snip] |
From: Will D. <wil...@ar...> - 2012-06-15 10:08:04
|
This patch adds support for parsing the cpu type from /proc/cpuinfo on ARM platforms and hooks this into __get_cpu_type_alt_method so that perf-events can be used as the backend. Signed-off-by: Will Deacon <wil...@ar...> --- libop/op_cpu_type.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 57 insertions(+), 0 deletions(-) diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c index 34b20e7..2df9cde 100644 --- a/libop/op_cpu_type.c +++ b/libop/op_cpu_type.c @@ -14,6 +14,7 @@ #include <string.h> #include <sys/utsname.h> #include <ctype.h> +#include <errno.h> #include "op_cpu_type.h" #include "op_hw_specific.h" @@ -162,6 +163,59 @@ static op_cpu _get_ppc64_cpu_type(void) return op_get_cpu_number(cpu_type_str); } +static op_cpu _get_arm_cpu_type(void) +{ + unsigned long cpuid, vendorid; + char line[100]; + char * cpu_part, * cpu_implementer; + + cpu_implementer = _get_cpuinfo_cpu_type(line, 100, "CPU implementer"); + if (!cpu_implementer) + return CPU_NO_GOOD; + + errno = 0; + vendorid = strtoul(cpu_implementer, NULL, 16); + if (errno) { + fprintf(stderr, "Unable to parse CPU implementer %s\n", cpu_implementer); + return CPU_NO_GOOD; + } + + cpu_part = _get_cpuinfo_cpu_type(line, 100, "CPU part"); + if (!cpu_part) + return CPU_NO_GOOD; + + errno = 0; + cpuid = strtoul(cpu_part, NULL, 16); + if (errno) { + fprintf(stderr, "Unable to parse CPU part %s\n", cpu_part); + return CPU_NO_GOOD; + } + + if (vendorid == 0x41) { /* ARM Ltd. */ + switch (cpuid) { + case 0xb36: + case 0xb56: + case 0xb76: + return op_get_cpu_number("arm/armv6"); + case 0xb02: + return op_get_cpu_number("arm/mpcore"); + case 0xc08: + return op_get_cpu_number("arm/armv7"); + case 0xc09: + return op_get_cpu_number("arm/armv7-ca9"); + } + } else if (vendorid == 0x69) { /* Intel xscale */ + switch (cpuid >> 9) { + case 1: + return op_get_cpu_number("arm/xscale1"); + case 2: + return op_get_cpu_number("arm/xscale2"); + } + } + + return CPU_NO_GOOD; +} + static op_cpu _get_x86_64_cpu_type(void) { // TODO: Horrible HACK!!! @@ -182,6 +236,9 @@ static op_cpu __get_cpu_type_alt_method(void) if (strncmp(uname_info.machine, "ppc64", 5) == 0) { return _get_ppc64_cpu_type(); } + if (strncmp(uname_info.machine, "arm", 3) == 0) { + return _get_arm_cpu_type(); + } return CPU_NO_GOOD; } -- 1.7.4.1 |
From: Maynard J. <may...@us...> - 2012-06-15 18:41:37
|
On 06/15/2012 05:07 AM, Will Deacon wrote: > Hello, > > Following on from Maynard's post advertising the perf-events branch: > > http://sourceforge.net/mailarchive/message.php?msg_id=29390076 > > These couple of patches add support for ARM cores to operf. There are a > number of recent ARMv7 cores that I will support in additional patches > (I just need to sit down and write the events files) when this has > settled down. > > I'm posting this as an RFC due to the following hurdles: > > 1.) I've probably broken ppc64 with my /proc/cpuinfo parser changes but > I don't have a relevant machine on which to test the patch. Works great on ppc64, too! Thanks for factoring out the /proc/cpuinfo scanning code. > > 2.) Cross-compiling for ARM doesn't work and I see the following error > during configure: > > checking kernel version supports perf_events... This kernel has perf_events support > checking for "/usr/include/linux/perf_event.h"... configure: error: cannot check for file existence when cross compiling > > perhaps we should have a --with-perf-events option or something > similar? Agreed. > > 3.) operf requests exclude_idle=1 in the perf_event_attr passed to the > kernel. ARM cores do not support this mode exclusion and requesting > it will give you -EPERM (which is the wrong error code -- I'll fix > this in the kernel...). Yes, as I think about it now, we should NOT exclude_idle by default since native events are designed to either include or exclude events while idle; for example, on ppc64, we have PM_CYC and PM_RUN_CYC, where the former counts all cycles, even in idle, and the latter counts cycles only when the run latch is set. So I will change this. Thanks much for your testing, your comments, and your code contribution. -Maynard > > All feedback welcome, > > Will > > > Will Deacon (2): > Factor out ppc64 /proc/cpuinfo parsing > Add ARM cpu type parsing using /proc/cpuinfo > > libop/op_cpu_type.c | 132 +++++++++++++++++++++++++++++++++++++++----------- > 1 files changed, 103 insertions(+), 29 deletions(-) > |
From: Maynard J. <may...@us...> - 2012-06-15 18:54:46
|
On 06/15/2012 05:07 AM, Will Deacon wrote: > This patch adds support for parsing the cpu type from /proc/cpuinfo on > ARM platforms and hooks this into __get_cpu_type_alt_method so that > perf-events can be used as the backend. > > Signed-off-by: Will Deacon <wil...@ar...> > --- > libop/op_cpu_type.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 57 insertions(+), 0 deletions(-) Patch committed, along with patch 1 -- so there's just one upstream commit for both patches. Thanks again. -Maynard [snip] |
From: Will D. <wil...@ar...> - 2012-06-18 11:07:06
|
On Fri, Jun 15, 2012 at 07:53:54PM +0100, Maynard Johnson wrote: > On 06/15/2012 05:07 AM, Will Deacon wrote: > > This patch adds support for parsing the cpu type from /proc/cpuinfo on > > ARM platforms and hooks this into __get_cpu_type_alt_method so that > > perf-events can be used as the backend. > > > > Signed-off-by: Will Deacon <wil...@ar...> > > --- > > libop/op_cpu_type.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 files changed, 57 insertions(+), 0 deletions(-) > Patch committed, along with patch 1 -- so there's just one upstream commit for both patches. Thanks again. Cheers Maynard, that's great. Will |
From: Will D. <wil...@ar...> - 2012-06-18 11:16:03
|
On Fri, Jun 15, 2012 at 07:41:19PM +0100, Maynard Johnson wrote: > On 06/15/2012 05:07 AM, Will Deacon wrote: > > These couple of patches add support for ARM cores to operf. There are a > > number of recent ARMv7 cores that I will support in additional patches > > (I just need to sit down and write the events files) when this has > > settled down. Well, I started looking at adding support for A5, A7 and A15 and noticed that our common ARMv7 events are somewhat out-of-date (new reserved events have been added to the architecture). Furthermore, ARM now provides recommended mnemonics and descriptions for these architected events. Would changing the event names be acceptable or is that considered an ABI break? The change is slightly more than cosmetic in that it would guarantee uniqueness between the micro-architectural events and those defined by the architecture which is required for what we want. Thoughts? Will |
From: Maynard J. <may...@us...> - 2012-06-18 12:25:59
|
On 06/18/2012 06:15 AM, Will Deacon wrote: > On Fri, Jun 15, 2012 at 07:41:19PM +0100, Maynard Johnson wrote: >> On 06/15/2012 05:07 AM, Will Deacon wrote: >>> These couple of patches add support for ARM cores to operf. There are a >>> number of recent ARMv7 cores that I will support in additional patches >>> (I just need to sit down and write the events files) when this has >>> settled down. > > Well, I started looking at adding support for A5, A7 and A15 and noticed > that our common ARMv7 events are somewhat out-of-date (new reserved events > have been added to the architecture). Furthermore, ARM now provides > recommended mnemonics and descriptions for these architected events. > > Would changing the event names be acceptable or is that considered an ABI > break? The change is slightly more than cosmetic in that it would guarantee > uniqueness between the micro-architectural events and those defined by the > architecture which is required for what we want. Will, Since event name changes affect only the users of the affected architecture, I feel that the decision make such changes is best left in the hands of the architecture maintainers. *Richard* is technically the ARM sub-maintainer for the oprofile project, so I'd like his opinion. But as the main ARM contributor, your opinion will count heavily. Changes such as these could be documented in the release notes. -Maynard > > Thoughts? > > Will > |
From: Will D. <wil...@ar...> - 2012-06-18 15:55:38
|
Hi Maynard, On Mon, Jun 18, 2012 at 01:25:42PM +0100, Maynard Johnson wrote: > On 06/18/2012 06:15 AM, Will Deacon wrote: > > Well, I started looking at adding support for A5, A7 and A15 and noticed > > that our common ARMv7 events are somewhat out-of-date (new reserved events > > have been added to the architecture). Furthermore, ARM now provides > > recommended mnemonics and descriptions for these architected events. > > > > Would changing the event names be acceptable or is that considered an ABI > > break? The change is slightly more than cosmetic in that it would guarantee > > uniqueness between the micro-architectural events and those defined by the > > architecture which is required for what we want. > Will, > Since event name changes affect only the users of the affected architecture, I feel that the decision make such changes is best left in the hands of the architecture maintainers. *Richard* is technically the ARM sub-maintainer for the oprofile project, so I'd like his opinion. But as the main ARM contributor, your opinion will count heavily. Changes such as these could be documented in the release notes. Sure, let's see what Richard says. I'll hold fire on the new cores until we've sorted out the event mnemonics. Cheers, Will |
From: Maynard J. <may...@us...> - 2012-06-22 18:40:44
|
On 06/18/2012 10:55 AM, Will Deacon wrote: > Hi Maynard, > > On Mon, Jun 18, 2012 at 01:25:42PM +0100, Maynard Johnson wrote: >> On 06/18/2012 06:15 AM, Will Deacon wrote: >>> Well, I started looking at adding support for A5, A7 and A15 and noticed >>> that our common ARMv7 events are somewhat out-of-date (new reserved events >>> have been added to the architecture). Furthermore, ARM now provides >>> recommended mnemonics and descriptions for these architected events. >>> >>> Would changing the event names be acceptable or is that considered an ABI >>> break? The change is slightly more than cosmetic in that it would guarantee >>> uniqueness between the micro-architectural events and those defined by the >>> architecture which is required for what we want. >> Will, >> Since event name changes affect only the users of the affected architecture, I feel that the decision make such changes is best left in the hands of the architecture maintainers. *Richard* is technically the ARM sub-maintainer for the oprofile project, so I'd like his opinion. But as the main ARM contributor, your opinion will count heavily. Changes such as these could be documented in the release notes. > > Sure, let's see what Richard says. I'll hold fire on the new cores until > we've sorted out the event mnemonics. Will, Richard has gone dark and is not responding to my ping on #oprofile IRC in the last two days. I would say you should proceed with your plan, and if Richard comes in later with comments, we'll deal with them then. -Maynard > > Cheers, > > Will > |
From: Will D. <wil...@ar...> - 2012-06-25 10:05:06
|
On Fri, Jun 22, 2012 at 07:40:19PM +0100, Maynard Johnson wrote: > On 06/18/2012 10:55 AM, Will Deacon wrote: > > Sure, let's see what Richard says. I'll hold fire on the new cores until > > we've sorted out the event mnemonics. > Will, > Richard has gone dark and is not responding to my ping on #oprofile IRC in the last two days. I would say you should proceed with your plan, and if Richard comes in later with comments, we'll deal with them then. Right-o. Interestingly, I got a mail delivery error for his @openedhand.com address used in this thread, so it may be that he's having mail issues. Once I've got through my current list of stuff to do I'll revisit the event encodings and cook up an RFC. Thanks, Will |