Corey,
On Sat, May 30, 2009 at 12:01 AM, Corey Ashford
<cjash...@linux.vnet.ibm.com> wrote:
>
>
> Philip Mucci wrote:
>>
>> Hi Stefane,
>>
>> Yeah, we talked about this on the phone. I personally think an attribute
>> versus a umask is an unnecessary semantic distinction. Both could be
>> handled by the umask mechanism as far as I can see.
>> i.e. When you parse a umask, you see an equal sign, you treat it as
>> such... Further, umasks can simply be seen as shorthand for the attribute
>> umask=true or something to that effect. In this way, we also don't need any
>> new API calls specific to attributes...
>>
>> Let's see what other folks think..
>>
>
> I agree with this. I think it makes it easier to understand the interface
> too... "What's the difference between a umask and an attribute, exactly?", I
> would want to know. We could call them all attributes, or all umasks.
> Personally, I prefer the term attribute, as it gets at the heart of what
> they are for.
>
The main difference is: umask have no user-controllable values
The value of a umask is hardcoded in the event table.
An attribute has a value which can be specified by the user at runtime: k=1
You could convert a umask, e.g., ANY_P, into an attribute by defining a generic
attribute: umask=0x345.
I admit this is somewhat confusing. We could call everything an attribute.
Umask would be an attribute without the possibility of assigning a value.
The following would be a valid specification:
INST_RETIRED:ANY_P:k=1:u=1
When parsing, the = sign would help libpfm figure out what each element is.
if (has('='))
lookup_attr(str);
else
lookup_umask(str)
The reason I am splitting the two here is because of the way attributes would
be encoded compared to umasks. Umask would remain as they are. Attributes
would be defined per event. But they would not necessarily need to be hardcoded
in the event table. For most PMUs, all events would have the same list
of attributes
therefore no need to encode them in the table.
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.
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()
Today, for listing, we iterate over the opaque event identifiers. A simple
for loop is enough because there is an assumption that identifier are
contiguous starting from 0. This logic would remain. No need for
pfmlib_event_t here.
In terms of querying, we are currently relying on the event
and umask identifiers. Those identifiers are retrieved via specific
calls such as pfm_find_full_event(). Identifiers are returned as
part of pfmlib_event_t. Without that, all query calls would have
to operate on the event specification directly. For instance, to
query the list of unit masks for an event:
pfm_get_event_mask_name("INST_RETIRED", 0, name);
Would return the name of unit mask 0 for INST_RETIRED.
How would attributes with values be exposed to users for querying?
It is useful for tools to list attributes with values, maybe to
print more customized error messages. Pfmon does some of that
today.
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.
> 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?
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.
>
> I have a few comments about "libpfm: event table encoding":
>
> One of the things I like about libpfm is that the tables are hard-coded
> which means they are always there and libpfm doesn't have to contain a bunch
> of crumbly logic to locate the events file (and possibly find the wrong
> one). Java has a nice way of dealing with issues like this, where a class
> can read a file contained in its own jar file (which a user could replace
> with his own version), but I don't think .so files have any such mechanism,
> but there are packaging technologies for most *nixes that would handle this
> just fine (rpm, etc.).
>
I also like it the way it is because everything is included. You can simply
ship a single .so file. No parsing required. Of course, libpfm is never shipped
as a .so but rather an RPM and DEB package. Therefore, there is always a
possibility to distribute more than just the .so file. But as you said, it pulls
in quite some code, or external dependencies.
> I think there's little motivation to go with anything other than XML for
> this, if you want to do it. There are some decent XML parsing libraries out
> there that should suit the needs of libpfm (expat and libxml2). You'd
> probably want to distribute an XML schema or DTD file for each architecture
> too, so that the libpfm could validate that the syntax of the event file is
> correct for that arch. Functions for both are in libxml2. I should be
> clear to say that I have never used either library, but I have used similar
> libraries in Java.
>
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.
> Once you read in the XML file and convert it to an in-memory structure, you
> wouldn't need to access the file system anymore. So I'm not sure where the
> "bursty accesses on shared storage" problem comes in.
>
The worry is about accessing the XML file. Imagine you launch a measurement
over a 10,000-node cluster that uses shared storage for the file. All
10,000 nodes
would go read the XML file pretty much at the same time.
> 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 ;-<
I think the issue about hardcoded vs. XML event table is secondary compared
to the issues related to umasks and attributes. Let's solve that part first.
Thanks.
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
