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 18:06:01 +0100 [thread overview]
Message-ID: <20121120170601.GR2504@rric.localhost> (raw)
In-Reply-To: <20121120165517.GC27765@mudshark.cambridge.arm.com>
On 20.11.12 16:55:17, Will Deacon wrote:
> On Tue, Nov 20, 2012 at 04:31:58PM +0000, Robert Richter wrote:
> > I am thinking of the following:
> >
> > # cat /root/cpu_type
> > arm/armv7-ca5
> > # cat /dev/oprofile/cpu_type
> > unknown
> > # mount --bind /root/cpu_type /dev/oprofile/cpu_type
> > # cat /dev/oprofile/cpu_type
> > arm/armv7-ca5
> >
> > From here legacy oprofile tools work as expected using oprofilefs. (I
> > think. Did not test it.) We need to change the kernel for this a bit
> > to return 'unknown'. The mount could be done by the oprofile tools
> > using existing cpu detection code. This is only one way to setup
> > cpu_type from userland, there could be other ways too.
>
> Ok, this is functionally equivalent to the patch that was submitted at the
> start of this thread: it solves the problem of mapping a single ARM core to
> a oprofile's CPU ID string. Technically, I don't mind doing that in the
> kernel (at least, it means you don't need to do your trick above)
The advantage of a solution where userland updates cpu_type is that we
never need to update the kernel anymore. This means, cpu detection can
be part of the tools.
-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 18:06:01 +0100 [thread overview]
Message-ID: <20121120170601.GR2504@rric.localhost> (raw)
In-Reply-To: <20121120165517.GC27765@mudshark.cambridge.arm.com>
On 20.11.12 16:55:17, Will Deacon wrote:
> On Tue, Nov 20, 2012 at 04:31:58PM +0000, Robert Richter wrote:
> > I am thinking of the following:
> >
> > # cat /root/cpu_type
> > arm/armv7-ca5
> > # cat /dev/oprofile/cpu_type
> > unknown
> > # mount --bind /root/cpu_type /dev/oprofile/cpu_type
> > # cat /dev/oprofile/cpu_type
> > arm/armv7-ca5
> >
> > From here legacy oprofile tools work as expected using oprofilefs. (I
> > think. Did not test it.) We need to change the kernel for this a bit
> > to return 'unknown'. The mount could be done by the oprofile tools
> > using existing cpu detection code. This is only one way to setup
> > cpu_type from userland, there could be other ways too.
>
> Ok, this is functionally equivalent to the patch that was submitted at the
> start of this thread: it solves the problem of mapping a single ARM core to
> a oprofile's CPU ID string. Technically, I don't mind doing that in the
> kernel (at least, it means you don't need to do your trick above)
The advantage of a solution where userland updates cpu_type is that we
never need to update the kernel anymore. This means, cpu detection can
be part of the tools.
-Robert
next prev parent reply other threads:[~2012-11-20 17:06 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
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 [this message]
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=20121120170601.GR2504@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.