stephane eranian wrote: > On Tue, Nov 24, 2009 at 9:29 PM, Corey Ashford > <cjash...@linux.vnet.ibm.com> wrote: >> Hi Stephane, >> >> stephane eranian wrote: >>> Hi, >>> >>> Ok, so I fixed libpfm4 such that it defaults to user mode, unless the >>> user specify a plm attribute in the event string. This is not in GIT yet. >>> >>> For instance: >>> llc_misses -> user only >>> llc_misses:k -> kernel only >>> llc_misses:k=0 -> neither kernel nor user >>> llc_misses:u=1:k=0 -> user only >>> >>> That got me into thinking that it would probably make more sense to >>> NOT have libpfm4 >>> try to force a priv level, but instead have the user pass a default >>> priv level, in case >>> none is specified in the event string. In libpfm3, this is how this >>> works. User must pass >>> a dfl_plm, otherwise pfm_dispatch_events() fails. So we could change >>> the API to be >>> >>> int pfm_get_event_encoding(char *str, int dfl_plm, uint64_t *values, >>> int *count); >>> int pfm_get_perf_event_encoding(char *str, int dfl_plm, struct >>> perf_event_attr *attr); >>> >>> >> >> This is fine for plm, but there could be other similar default modifiers >> that are needed. For example, invert might have a default value of true for >> some events and false for others. I think the user should have a way of >> querying the defaults, then formulating an event string based on an >> alteration of the defaults (if desired). And I think libpfm should be the >> repository of such default information. >> > But then, if invert is defined, this is part of a predefined unit mask. > Some events on x86 do that. In that case, libpfm refuses to change > to value of the attribute. > >> Perhaps, we could add a new api call >> >> pfm_get_event_attr_dfl(int idx, int attr_idx, uint64_t *attr_val); >> > > I suspect you meant: > > pfm_get_event_attr_dfl(int idx, int attr_idx, int *attr_vals, int > *n_attrs); > > For a given event, idx, and unit mask, attr_idx, return the opaque identifier > for any default attribute.
I wasn't thinking in terms of umasks before, because our A2 processor won't need umasks (as I understand them), just event modifiers. I was thinking of getting the default values one at a time, but getting an entire array of them is ok too. So let's take your prototype, tweak it a little and I'll tell you what I'd want out of it. pfm_get_event_attr_dfl(int idx, int attr_idx, int *attr_idxs, int *attr_dfls, int *n_attrs); For a given event, idx, and umask, attr_idx, return an array of attribute indices for those attributes which have defaults in attr_idxs, an array of attribute defaults in attr_dfls, and the number of attributes in n_attrs. This way, I know the indexes of the attributes which have defaults, and the default values for those same attributes. > >> And it would return the default value in attr_val. (I seem to recall >> there's a string attribute type too, but I must be mistaken because it >> doesn't appear to be one of the possible attribute types) >> >> What do you think of this idea as an alternative to the special purpose >> dfl_plm param? >> > With your proposal, how would you solve the issue of a default priv level? A user level tool could call this function, figure out which attributes it was interested in (via their names), and then append to the event:umask string any modifications to the defaults that it needs. For example, it detects that k=1 when it needs it set to zero, so it specifies event:umask:k=0 I see this being used in an interactive way, too: a user would be able list events (perhaps via showevtinfo), their attributes, and defaults, and then decide how to create an event specifier string based on this info. - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 cjash...@us.ibm.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
