From: Scott Wood <scottwood@freescale•com>
To: Paul Mackerras <paulus@samba•org>
Cc: linuxppc-dev@ozlabs•org
Subject: Re: [PATCH] perf_event: e500 support
Date: Thu, 11 Feb 2010 10:56:28 -0600 [thread overview]
Message-ID: <4B7436BC.10406@freescale.com> (raw)
In-Reply-To: <20100211030143.GA11245@brick.ozlabs.ibm.com>
Paul Mackerras wrote:
> On Wed, Feb 10, 2010 at 06:06:10PM -0600, Scott Wood wrote:
>
>> Paul Mackerras wrote:
>>>> Some limitations:
>>>> - No threshold support -- need to figure out how to represent it in
>>>> the event struct from userspace.
>>> What does "threshold support" mean in this context? Does it mean
>>> something different from getting an interrupt after N events have been
>>> counted? Or does it mean counting instances where something takes
>>> longer than a specific number of cycles?
>> The latter.
>
> OK. I handled that on classic by using some extra high bits in the
> event config for the threshold value.
OK.
> If you have a single threshold
> value in hardware but more than one event that uses that threshold
> value, then you will need to add a constraint that all threshold
> events have to specify the same threshold.
There's a separate threshold for each counter.
> So, it sounds like you have a class of events which are the
> thresholding events, and two constraints:
>
> * at most two events in the thresholding event class
> * at most four events in total
>
> Are there other constraints? Apart from the thresholding events, can
> any event go on any counter, or can some events only be counted on one
> particular counter?
No, those are the only constraints.
> If your constraints are just the two listed above (<= 2 threshold
> events, <= 4 events total), then doing it the obvious straightforward
> way is fine. If there are other constraints as well, such as certain
> events only being available on one specific PMC, then you should
> consider reusing the constraint checking machinery from ppc64.
I'll stick with the straightforward approach then. If future chips have
more complicated constraints we can revisit using the more general scheme.
-Scott
next prev parent reply other threads:[~2010-02-11 16:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-15 21:43 [PATCH] perf_event: e500 support Scott Wood
2010-02-10 22:29 ` Paul Mackerras
2010-02-11 0:06 ` Scott Wood
2010-02-11 3:01 ` Paul Mackerras
2010-02-11 16:56 ` Scott Wood [this message]
2010-02-18 3:33 ` Kumar Gala
2010-02-18 9:27 ` Paul Mackerras
2010-02-18 3:29 ` Kumar Gala
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=4B7436BC.10406@freescale.com \
--to=scottwood@freescale$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=paulus@samba$(echo .)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