Corey,
On Tue, Jun 2, 2009 at 12:53 AM, Corey J Ashford <cjash...@us.ibm.com> wrote:
>>
>> Would we still need a binary representation of events via
> pfmlib_event_t?
>>
>> Not for PCL, not even for perfmon because the pfm_dispatch_events()
> could
>> take the event specification strings directly, via an argv-style
> argument.
>
> True. Just a quick anecdote here about that: My collegue Carl Love had
> never worked on libpfm before, and when he looked at the pfm_dispatch
> call, he was a little confused not to find a list of event name strings
> passed in. So I think this would be a natural thing to do, to change the
> dispatch function to accept the full event strings, and that would get rid
> of the need for many programmers to call the individual event and umask
> lookup functions first.
>
Yes, I think it is more natural, though parsing would be repeated for each call.
But this is never on the critical path on an application, so it should be okay.
>>
>> They are several more issues to address however:
>> 1 - listing of events and umasks
>> 2 - querying of event special features, e.g., pfm_nhm_event_is_pebs()
>>
>> Attributes would be logically added to the list of existng umasks.
>> Let's take an example:
>>
>> { .pme_name = "INST_RETIRED",
>> .pme_code = 0xc0,
>> .pme_desc = "Instructions retired",
>> .pme_umasks = {
>> { .pme_uname = "ANY_P",
>> .pme_udesc = "Instructions retired (precise event)",
>> .pme_ucode = 0x0,
>> .pme_flags = PFMLIB_CORE_PEBS
>> },
>> { .pme_uname = "LOADS",
>> .pme_udesc = "Instructions retired, which contain a
> load",
>> .pme_ucode = 0x1
>> },
>> { .pme_uname = "STORES",
>> .pme_udesc = "Instructions retired, which contain a
> store",
>> .pme_ucode = 0x2
>> },
>> { .pme_uname = "OTHER",
>> .pme_udesc = "Instructions retired, with no load or
>> store operation",
>> .pme_ucode = 0x4
>> }
>> },
>> .pme_numasks = 4
>> },
>>
>> Assuming this event supports attributes: i, e, c, u ,k
>>
>> That means that it exposes 4 + 5 = 9 attributes
>> 4 are actually encoded in the event table. 5 are dynamically added.
>> So you can actually iterate from 0-8 with pfm_get_event_mask_name().
>>
>> One thing which is still missing here is the ability to query valid
> values
>> for an attribute. For instance, the c attribute (counter-mask) is only
> 8-bit
>> wide. Libpfm will reject any value > 255. But it would be nice for tools
>> to have a way of knowing this limit. Of course, the difficulty is the
> type
>> of the value. In the current scheme, the value may not necessarily be an
>> integer.
>
> Yes, that's a tough problem because it's difficult to foresee every
> possible attribute value that might be needed.
In my mind, attributes exist in the arch-specific layer, not in the generic
code. Therefore there is nothing to predict. All you need is a lookup
mechanism to parse the string. Then the (attr, value) pair is passed to
the model-specific layer for processing. the generic layer is responsibly
for 'tokenizing' the string into (attr, value) pairs. Those are then passed
to the model-specific layer.
> I suppose you could define a few common types that could be used:
> 1) an enum: e.g. LEVEL, EDGE
> 2) a decimal range m .. n
> 3) a hexadecimal range h .. i
>
> A specific architecture implementation could use one of the above, and
> libpfm would know how to describe and check those. Or it could implement
> its own type, by supplying callbacks for libpfm to call. Two callbacks
> might be:
>
Libpfm at some level would always be able to check the validity of values.
If it is in the generic layer, then there needs to be a way to express the
valid values. I think this could remain in the machine specific layer.
I was after trying to expose some of this to tools because that would help
them guide their users with customized early error messages. But I think
for now, we could live with a specific error code, to flag the case of invalid
attribute value.
>> > As for the encoding of PCL events, I like the idea of unifying the
>> > user/kernel/supervisor as attributes/umasks and then processing that
> into an
>> > entire pcl perf_hw_counter struct. However, libpfm has attempted to
>> > disconnect itself from the kernel implementation, and adding this sort
> of
>> > kernel-specific function is taking a rather long drive down that road.
> Plus
>> > it makes libpfm more closely tied to the version of PCL which is in
> the
>> > kernel. In that light, at least until PCL settles down very well, I
> think
>> > the "simply provide raw encoding (no PCL encoding)" option would be
>> > preferable. (by the way, is the "uint64_t vals" param supposed to be
> a
>> > pointer "uint64_t *vals" ?)
>> >
>> I like the idea of keeping libpfm internals disconnected from a kernel
>> API. But I am wondering about the level of support provided by a libpfm
>> which only returns uint64_t *vals. Don't get me wrong, though, I think
>> this call is useful. But it is useful enough, don't tools want more
> help?
>
> Well, this level of support was enough for the PAPI PCL substrate, but
> that's not everyone, I know.
>
What this does is shift some of the burden onto the tool or a additional
PCL library. There is work you are doing in your PAPI - PCL shim layer
to support generic HW and SW events. That work would have to be
repeated for every tool interested in those generic events. And they
all are because those events guarantee some minimal functionalities.
And for generic events, you'd like to define some attributes, at least
the priv level. And for that you'd like to use the same syntax as for the
raw PMU events. The priv level would be used to set the exclude_* fields.
That means, you would have to duplicate the string parsing code in libpfm.
And that's a pain, I think.
>>
>> Should libpfm only be concerned by actual PMU hardware events?
>> In other words, should it not deal with PCL generic HW events, such
>> as PERF_COUNT_CPU_CYCLES, and SW events, such as
>> PERF_COUNT_PAGE_FAULTS? If it does not, then it means each
>> tool needs to have another layer which intercepts those events and
>> only calls libpfm when the event is not recognized. Similarly, the type
>> bitfield inside the config field should be written by the caller of
> libpfm
>> and not libpfm.
>
> Since there are not a huge number of predefined PCL events, I think it
> would make sense for libpfm to handle them also. If you can generalize
> the support in libpfm so that it potentially could be extended to
> generalized events using other kernel implementations (say on BSD), that
> would be good (and I'm guessing not too difficult).
>
> More along those lines, you might want to consider partitioning libpfm
> into a generic piece, and a kernel-specific piece, sort of like how PAPI
> has its substrates.
>
Yes, that's a good way. That's how I have been experimenting with libpfm
for PCL support: add a pfmlib_pcl.h specific header + pfmlib_pcl.c.
>> Yes, XML like syntax would be used. I am no expert in this. What I care
>> about is the extensibility of the description. As you know, each PMU may
>> have to define model-specific attributes in the event table. Yet we
> don't
>> want to patch the lexical analyzer and parser for each new PMU model.
>
> Yeah, with XML, if you are reasonably careful with designing the schema
> (for example, don't use attributes too much), you can make the description
> for each PMU very extensible, and add new features later on without
> breaking the previous ones.
>
That's what I'd like to see.
> Since the parser and lex analyzer is built into the libxml2 and expat
> libraries, there's really very little work to do with that part. It does
> all of the heavy-lifting and error detection.
>
Exactly.
>>
>> > If you accessed the XML tables via the DOM, the potential is there to
> use
>> > more memory than would be required by having loaded the hard-coded
> event
>> > tables for all arches. However, if you use SAX instead, the memory
> overhead
>> > should be minimal, and both expat and libxml2 support a SAX interface.
>> >
>> I don't know what DOM and SAX are ;-<
>
> Very simply, with the DOM (Document Object Model), you can randomly access
> the XML tree using paths to get to particular nodes, iterate through them,
> etc. With SAX, you provide callbacks for the XML parser to call as it
> parses each XML element in the tree. Once it has parsed the whole XML
> file, you no longer use the XML library, and simply deal with whatever
> data you've stored as a result of the parsing callbacks.
>
I think you'd want the SAX model in this case. That would get us back
to what we have today: PMU-specific event table format. But I think it
could be relaxed to arch-specific event table format. C format would
be extende if needed and XML schema would be extended accordingly.
>
> I agree. Just thought I'd throw that XML stuff in there since I do have
> some experience with it. Overall, XML is very nice to work with.
>
This is very helpful.
Thanks.
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
