From: rusty@rustcorp•com.au (Rusty Russell)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: test for PMU feature on v7 (v2 with typo fix)
Date: Wed, 28 Mar 2012 16:39:31 +1030 [thread overview]
Message-ID: <87pqbx9rz8.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120326094054.GA2475@mudshark.cambridge.arm.com>
On Mon, 26 Mar 2012 10:40:54 +0100, Will Deacon <will.deacon@arm•com> wrote:
> [removed some dead email addresses from CC]
Thanks!
> On Fri, Mar 23, 2012 at 11:17:07PM +0000, Rusty Russell wrote:
> > I had assumed that as we trend towards a common cross-platform kernel,
> > we should be relying on feature registers where available, not the
> > model.
>
> The PMU is very tightly coupled with the CPU and it is necessary to know
> exactly which CPU you have so that you can map microarchitectural events to
> their identifiers. This is not discoverable in the architecture [PMUv2
> provides some support for discovering the status of architected events, but
> that is still not enough and is only present on A7 and A15 so far] so that's
> why we probe the CPU instead.
OK.
> Now, if everything was device-tree based then we could simply use a
> different binding for each CPU but since we support perf on non-DT
> platforms, probing the CPU type is the best solution. I would like to avoid
> the probing code if we are initialised from DT, but I've not got round to it
> yet (this would be useful for big.LITTLE).
I'll be interested to see how you encode the mapping of
microarchitectural events to their identifiers here.
> > > Would you be able to advertise 0 event counters instead and treat the PMU
> > > largely as RAZ/WI? The only tricky bit I can see is the cycle counter, which
> > > is mandated by the presence of a PMU, however this could also just RAZ
> > > initially.
> >
> > Yes, that's the effect of the current emulation hack. Far better not to
> > lie to the guest, however, than get weird results from profiling.
>
> I'd rather lie to the guest than modify it just to avoid emulating the
> device correctly. Even then, the profiling results wouldn't be especially
> weird -- everything would be 0, which is a lot better than random
> numbers.
Sure, but nowhere as neat an experience as having "no hardware support
available" printed, and nicely defined failure mode :(
When I get back in May, I'll look at how hard it will to be implement
this properly, if noone else does.
Thanks,
Rusty.
--
How could I marry someone with more hair than me? http://baldalex.org
next prev parent reply other threads:[~2012-03-28 6:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4F590411.9060201@arm.com>
2012-03-23 0:32 ` [PATCH] ARM: test for PMU feature on v7 Rusty Russell
2012-03-23 0:34 ` [PATCH] ARM: test for PMU feature on v7 (v2 with typo fix) Rusty Russell
2012-03-23 9:53 ` Will Deacon
2012-03-23 23:17 ` Rusty Russell
2012-03-26 9:40 ` Will Deacon
2012-03-26 9:50 ` [Android-virt] " Peter Maydell
2012-03-26 15:15 ` Will Deacon
2012-03-28 6:09 ` Rusty Russell [this message]
2012-03-28 14:17 ` Nicolas Pitre
2012-03-30 17:04 ` Will Deacon
2012-03-30 17:40 ` Nicolas Pitre
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=87pqbx9rz8.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox