Corey,
On Tue, Jun 2, 2009 at 8:48 PM, Corey J Ashford <cjash...@us.ibm.com> wrote:
> Thanks for comments. Here are just a couple more:
>
> stephane eranian <eran...@googlemail.com> wrote on 06/02/2009 07:44:11 AM:
>
>> 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.
>
> It could, definitely. I was thinking you could factor some of the common
> types out so that each arch wouldn't have to re-invent their own parsers
> and validators.
>
Well, the way I have experimented with this is as follows:
- each PMU or arch specific module provides a callback get_attrs(int event).
For each event, the function returns a char **argv[] array which
list the supported
attributes, e.g., { "u", "k", "e", NULL}. The position in the array
represents an offset
which is added to the number of unit masks. Using this information,
the generic code
can "tokenize" the event string. For instance, INST_RETIRED has 4
unit masks, thus,
INST_RETIRED:ANY_P:k=1, would be tokenized as:
event=123 /* event index */
attrs[0].idx = 0; attrs[0].val =0; /* ANY_P */
attrs[1].idx = 5; attrs[1.val = 1 /* k = 1, 5 = 4 (unit masks +
offset in attr list).
That would then be passed to the PMU-specific layer which would not have to
do string parsing anymore, it would simply have a switch-case in a
loop to iterate
over attrs[]. That layer is the only one to know how to set the bits
that correspond
to k=1 and ANY_P.
>
> The current PCL substrate for PAPI doesn't deal with the PCL generic
> events or software events yet. I'm making use of the perfmon_events.csv
> file to get the "papi preset" events, which are not that closely related
> to the PCL generic events (and the new ones being considered for
> inclusion).
>
> You're right, though. That work would have to be done somewhere, and it
> would be nice to have a library (libpfm) doing a lot of it, especially if
> you do break out the PCL module (or layer, whatever you want to call it)
> as a separate thing.
>
This is what I have done, and that's why in my presentation would have
that specific call:
pfm_get_pcl_event_encoding().
That call knows about perf_hw_counter_event and it also knows about the
PCL generic events.
What's missing however, is the fact that you may want to see the generic
HW and SW events when you are listing events or querying specific event
attributes. But those calls are not PCL-aware. That's where, I hit a dilema:
keep PCL knowledge isolated to a module and specific calls, vs. exposing
it broadly to make all calls aware of generic events.
>
>> I think you'd want the SAX model in this case.
>
> Yes, SAX lends itself to this particular application very nicely.
> According to the libxml2 doc, the DOM is written using SAX, and so even
> though SAX is not a w3 standard, it should be pretty rugged due to heavy
> use.
>
>> 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.
>
> Yes, that makes good sense, at least for ppc64 where the PMU's all stem
> from a common design (with the exception of Cell). I would imagine that
> Intel x86 would be another arch and that AMD would be another one.
>
I think so.
> You still have the issue of burst accesses. Maybe we could think at some
> point of doing a "caching" operation where you compare the date on the XML
> file to the date on your cached and parsed event table which you've mmap
> and stored in a file from a previous session. If the XML file is older,
> you use the cached data. This would cut down the load time a great deal,
> and perhaps be almost as fast as the current hard-coded libpfm.so file
> mechanism.
>
I did talk to Phil about this a while ago. It seems in PAPI than also maintain
a hardcoded version. You an then setup PAPI to use either internal vs. external
or external if is exists otherwise internal. That provides maximum flexibility.
But then, of course, it does not address the size problem, it actually make it
worse because you have the hardcoded tables AND the XML logic.
------------------------------------------------------------------------------
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
