On Thu, Jun 4, 2009 at 4:03 PM, Dan Terpstra <terps...@eecs.utk.edu> wrote:
>
>
>> > 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.
>> >
>> It is solved if in a large cluster PAPI is configured to always use
>> the hardcoded
>> event table but at the price of losing the flexibility of the external
>> file.
>>
> PAPI provides a comma separated value text file that defines preset events
> in terms of native events. I would probably have preferred xml, but
> evolution and the path of least resistance produced this. Originally, it
was
> always read in and parsed at PAPI init time. That caused exactly the
problem
> you describe for large Cray clusters. Steve Kaufmann @ Cray came up with a
> quick script to convert the csv file into a header file and embed it in
the
> code. This has become the default option for building PAPI. The
flexibility
> is still available as an override primarily for development and testing.
The
> logic is still the same to parse the file; it's just parsed in place
instead
> of read in from the file system. This provides the quick load, but does
> increase the footprint.
It seems to me that the list of presets -> native events may be much smaller
than the actual PMU event table. Is that correct?
> It appears to me that libpfm compiles and includes event tables for every
> platform it supports. Is that correct? If so, it doesn't seem that
footprint
> is a major issue.
It does include all event tables for the architecture you're on. On x86, it
includes everything from Pentium II to Intel Core i7. Tables are in binary
format, yet still relatively easy to read. On x86-64, the data size of
libpfm
is about 580KB of a 57% of the libpfm.a image. Nobody ever complainedabout
that. But embedded space people definitively will! Of course, that
can be adjusted by only compiling support for what you need for your
embedded hardware.
> Also, would it be possible to source this info in an xml file that is then
> converted at build time to a compact binary representation for consumption
> by libpfm? That should reduce the size and increase the speed, but at the
This is how I generate the event tables for Intel processors already. But I
do
the conversion only once. Compact representation is a C table of structs.
I mean there is no further parsing of a binary file.
------------------------------------------------------------------------------
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
