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.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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.