On Fri, Jun 19, 2009 at 9:20 PM, stephane eranian<eran...@googlemail.com> wrote:
> On Fri, Jun 19, 2009 at 9:03 PM, Corey J Ashford<cjash...@us.ibm.com> wrote:
>> Hi Stephane,
>>
>> For these sort of events which require multiple pmds, how does libpfm
>> describe to the caller the formula for combining the values from the pmds?
>> Or is it expected that the caller knows how?
>
> It is expected the caller knows.
Well, libpfm4 would need to provide some help, at least to detect that an event
description is indeed special.
For instance, on AMD64, if I pass IBSOP_EVENT:m=0xfff0, then I will get
back one PMC and 7 PMDS. The tool somehow need to know user has requested
IBS and that special handling is required.
We could do something such as:
int pfm_amd64_event_ibsop(const char *str);
int pfm_amd64_event_ibsfetch(const char *);
On Intel, we could also provide helpder functions for the various
flavors of PEBS.
The way I have set it up now, is that you can pass a pebs attribute to
events which
do support PEBS, if set it means caller wants to use the event with
PEBS. For instance,
INST_RETIRED:ANY_P:pebs=1
Thus, we could provide:
int pfm_intel_event_pebs(const char *str);
> With libpfm-3.x that was explicit because the caller had to pass a
> PMU-specific
> data structure.
>
>>
>> - Corey
>>
>>
>> stephane eranian <eran...@googlemail.com> wrote on 06/19/2009 10:24:29 AM:
>>
>>> Dan,
>>>
>>> Here is another libpfm4-related question.
>>>
>>> One thing that is quite bad with the current libpfm-3.x is that
>>> you pass events and get back PMCs and PMDs but it is not
>>> obvious which register corresponds to which event. The mapping
>>> is not always 1-to-1. Take Intel Core, you can pass unhalted_core_cycles
>>> and instructions_retired, that would go into a single PMCs and two
>>> PMDs. In general tools, do not really care about PMCs, they get them
>>> back and pass them to the kernel (perfmon does not allow reading back
>>> of the PMCs). But you need to know which data register to read, so
>>> you can collect your data.
>>>
>>> There is an implicit rule inside libpfm which says that PMD for events
>>> are returned IN THE ORDER of the events. And it assumes a one-to-one
>>> mapping: 1 event = 1 data register. This is pretty basic and has worked
>>> okay until now.
>>>
>>> With libpfm4, everything is represented as an event, not just the actual
>>> events but also AMD64 IBS, Intel LBR. Thus, there needs to be a more
>>> robust way of mapping events -> registers.
>>>
>>> Ideally, you'd want libpfm to return the list of PMCs and PMDs that
>> correspond
>>> to each event. For instance:
>>> struct {
>>> pfmlib_reg_t pmcs[];
>>> pfmlib_reg_t pmds[]
>>> };
>>>
>>> In some cases, the PMCs of two events could be identical, e.g.,
>>> Intel Core fixed
>>> counters. But usually PMD would always be distinct. But the above
>> proposal is
>>> overkill and consumes quite a bit of memory, unless all of this is
>> dynamically
>>> allocated.
>>>
>>> The current alternative I am experimenting with is that for each
>>> register returned,
>>> the index of the event is stored. Remember that pfm_dispatch_events()
>>> is replaced
>>> with pfm_assign_events(char **events_argv, pfmlib_assign_in_t *in,
>>> pfmlib_assign_out_t *out);
>>>
>>> If you pass:
>>> events_argv[0] = unhalted_core_cycles
>>> events_argv[1] = instructions_retired
>>>
>>> You will get back:
>>> out->pmds[0].reg_num = 17;
>>> out->pmds[0].reg_eventid = 0;
>>>
>>> out->pmds[1].reg_num = 16;
>>> out->pmds[1].reg_eventid = 1
>>>
>>> Thus, to find out what register(s) you need to read for
>>> unhalted_core_cycles, you have to scan
>>> out->pmds[] once, looking for eventid == 0.
>>>
>>> I know it is not ideal. But this works for multi-pmd events or
>>> pseudo-events such as AMD IBS.
>>> For instance, IBSOPFETCH: 1 PMC + 3PMDS
>>>
>>> Note that this scheme does not work too well for PMCS if they are
>>> shared by multiple events, such
>>> as on Intel Core for fixed counters. But my earlier point was that
>>> tool, do not really care as to which
>>> PMCs corresponds to which event.
>>>
>>> There are some alternatives such as returning a pair of bitmasks per
>>> event, one for the PMCs
>>> the other for the PMDs.
>>>
>>> I am open to suggestions on how to solve this better.
>>
>>
>
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
