From: rric@kernel.org (Robert Richter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] ARM: oprofile: add A5/A7/A15 entries in op_perf_name
Date: Tue, 20 Nov 2012 13:17:47 +0100 [thread overview]
Message-ID: <20121120121747.GJ2504@rric.localhost> (raw)
In-Reply-To: <20121105113102.GF3351@mudshark.cambridge.arm.com>
Will,
On 05.11.12 11:31:03, Will Deacon wrote:
> > diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
> > index 99c63d4b..ec10db1 100644
> > --- a/arch/arm/oprofile/common.c
> > +++ b/arch/arm/oprofile/common.c
> > @@ -37,8 +37,11 @@ static struct op_perf_name {
> > { "xscale1", "arm/xscale2" },
> > { "v6", "arm/armv6" },
> > { "v6mpcore", "arm/mpcore" },
> > + { "ARMv7 Cortex-A5", "arm/armv7-ca5" },
> > + { "ARMv7 Cortex-A7", "arm/armv7-ca7" },
> > { "ARMv7 Cortex-A8", "arm/armv7" },
> > { "ARMv7 Cortex-A9", "arm/armv7-ca9" },
> > + { "ARMv7 Cortex-A15", "arm/armv7-ca15" },
> > };
> I'd rather not go down this route now that we have the operf tool as part of
> oprofile, which can use the perf syscall directly and doesn't need this
> string translation.
since this is just an update of cpu detection I would be willing to
include this into kernel code anyway.
We could further move the cpu detection to userspace if perf_event
exists. We let the kernel enable oprofile with cpu_type="unknown".
User space then could either bind mount the file (user could do this
manually) or we implement to write to cpu_type. Doing so oprofile
could use in-kernel perf_events if it exists always as fallback.
Any thoughts?
-Robert
WARNING: multiple messages have this Message-ID (diff)
From: Robert Richter <rric@kernel.org>
To: Will Deacon <will.deacon@arm.com>
Cc: Maynard Johnson <maynardj@us.ibm.com>,
"jgq516@gmail.com" <jgq516@gmail.com>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"oprofile-list@lists.sf.net" <oprofile-list@lists.sf.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/1] ARM: oprofile: add A5/A7/A15 entries in op_perf_name
Date: Tue, 20 Nov 2012 13:17:47 +0100 [thread overview]
Message-ID: <20121120121747.GJ2504@rric.localhost> (raw)
In-Reply-To: <20121105113102.GF3351@mudshark.cambridge.arm.com>
Will,
On 05.11.12 11:31:03, Will Deacon wrote:
> > diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
> > index 99c63d4b..ec10db1 100644
> > --- a/arch/arm/oprofile/common.c
> > +++ b/arch/arm/oprofile/common.c
> > @@ -37,8 +37,11 @@ static struct op_perf_name {
> > { "xscale1", "arm/xscale2" },
> > { "v6", "arm/armv6" },
> > { "v6mpcore", "arm/mpcore" },
> > + { "ARMv7 Cortex-A5", "arm/armv7-ca5" },
> > + { "ARMv7 Cortex-A7", "arm/armv7-ca7" },
> > { "ARMv7 Cortex-A8", "arm/armv7" },
> > { "ARMv7 Cortex-A9", "arm/armv7-ca9" },
> > + { "ARMv7 Cortex-A15", "arm/armv7-ca15" },
> > };
> I'd rather not go down this route now that we have the operf tool as part of
> oprofile, which can use the perf syscall directly and doesn't need this
> string translation.
since this is just an update of cpu detection I would be willing to
include this into kernel code anyway.
We could further move the cpu detection to userspace if perf_event
exists. We let the kernel enable oprofile with cpu_type="unknown".
User space then could either bind mount the file (user could do this
manually) or we implement to write to cpu_type. Doing so oprofile
could use in-kernel perf_events if it exists always as fallback.
Any thoughts?
-Robert
next prev parent reply other threads:[~2012-11-20 12:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-02 10:43 [PATCH 1/1] ARM: oprofile: add A5/A7/A15 entries in op_perf_name jgq516 at gmail.com
2012-11-02 10:43 ` jgq516
2012-11-05 11:31 ` Will Deacon
2012-11-05 11:31 ` Will Deacon
2012-11-20 12:17 ` Robert Richter [this message]
2012-11-20 12:17 ` Robert Richter
2012-11-20 15:57 ` Will Deacon
2012-11-20 15:57 ` Will Deacon
2012-11-20 16:31 ` Robert Richter
2012-11-20 16:31 ` Robert Richter
2012-11-20 16:55 ` Will Deacon
2012-11-20 16:55 ` Will Deacon
2012-11-20 17:06 ` Robert Richter
2012-11-20 17:06 ` Robert Richter
2012-11-20 17:08 ` Will Deacon
2012-11-20 17:08 ` Will Deacon
2012-11-23 14:10 ` Robert Richter
2012-11-23 14:10 ` Robert Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121120121747.GJ2504@rric.localhost \
--to=rric@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.