stephane eranian wrote:
> 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.
That works fine for attributes with numeric values. There might be some arches
that would want to use atrributes with enum-like values. The PMU- or
arch-specific code would want some way of specifying the valid enum strings for
parsing by the generic code.
>
>> 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.
It seems like you could call the kernel-specific code for event numbers greater
than the pmu-specific hardware event numbers. Basically, you just need a way
to
plug in kernel-specific code that knows about the extra events exposed by it.
Something like:
int pfm_kernel_get_num_events()
char *pfm_kernel_get_event(int event);
For PCL, pfm_kernel_get_num_events() would return the number of software events
+ the number of generic events. libpfm would number these events
last_pmu_hardware_event + 1 .. (last_pmu_hardware_event +
pfm_kernel_get_num_events()).
So the "linearizing" of the PCL events into a single space (rather than a
separate software and generalized events) would be done by the PCL
kernel-specific code. And the ordering of the PMU-specific and kernel-specific
code would be done by the PCL generic code.
>> 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 they also maintain
> a hardcoded version. You can 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.
I don't think PAPI's solution really solves the "quick load time + small foot
print" issue for libpfm. If you just used caching, I think it solves both
problems, but would require that the XML file be available somewhere when
libpfm
is loaded up the first time. If the XML file is never modified from then on,
you'd always get the cached up data structure sitting in a file ready to be
mmap'd into libpfm's space.
- Corey
------------------------------------------------------------------------------
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
