Thanks for comments. Here are just a couple more: stephane eranian <eran...@googlemail.com> wrote on 06/02/2009 07:44:11 AM:
> Corey, > > On Tue, Jun 2, 2009 at 12:53 AM, Corey J Ashford <cjash...@us.ibm.com> wrote: > > 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. 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. > > 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. Yep. > > >> 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. 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. > 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. 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. - 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
