Gary,
On Thu, Jun 12, 2014 at 1:22 AM, Gary Mohr <gary.m...@bull.com> wrote:
> Hi Stephane,
>
>
>
> I was wondering about the ABI. Thanks for making me go figure out how
> that works. I learned something
>
>
>
> I moved the new “cntmsk” fields to the end of the info structures so that
> it no longer replaces an existing field.
>
> I also updated the PFM_EVENT_INFO_ABI0 values to account for the new
> field in both the event and event attribute structures.
>
> Are these variables also the ABI rev values you spoke about because I did
> not see anything else that looked like a revision.
>
>
>
> And finally I noticed that there was a place in the perf_event pmu code
> that needed to clear the cntmsk values. This prevents residue when getting
> information about the events in the perf_event pmu. Code to do this has
> been added to the new patch.
>
>
>
> So attached you will find a patch that hopefully can be committed to your
> GIT. But please let me know if there is anything else it needs.
>
>
>
I looked at the patch. I thought about a problem with the cntmsk field.
On Intel systems with Hyperthreading, there are 2 cntmsks possible, one
with HT on (up to 4 ocunters) and one with HT off (up to 8 counters). Your
patch (nor the library's internal) handle this correctly.
We have several options:
- Assume HT on all the time, return at most 4 generic counters in cntmsk
- return both masks (in a generic fashion)
- return the HT off mask
- auto-detect from host. If not running on targeted host, then pick one
mask
Second problem:
-#define PFM_EVENT_INFO_ABI0 64
-#define PFM_ATTR_INFO_ABI0 64
+#define PFM_EVENT_INFO_ABI0 72
+#define PFM_ATTR_INFO_ABI0 72
#define PFM_RAW_ENCODE_ABI0 32
#else
#define PFM_PMU_INFO_ABI0 44
-#define PFM_EVENT_INFO_ABI0 48
-#define PFM_ATTR_INFO_ABI0 48
+#define PFM_EVENT_INFO_ABI0 56
+#define PFM_ATTR_INFO_ABI0 56
Do not override ABI0, just define ABI1 and use
it internally. But if you are passed ABI0 struct
then handle them correctly, i.e. ,do not update the
cntmsk field.
That way you maintain backward compatibility with
older programs AND can service updated programs.
> Thanks
>
> Gary
>
>
>
> *From:* Stephane Eranian [mailto:eran...@googlemail.com]
> *Sent:* Sunday, June 08, 2014 12:49 PM
> *To:* Gary Mohr
> *Cc:* Philip Mucci; Vince Weaver; Heike McCraw; perfmon2-devel
>
> *Subject:* Re: RE: [Perfapi-devel] [perfmon2] FW: Proposed enhancement to
> libpfm4.
>
>
>
>
>
>
>
> On Tue, Jun 3, 2014 at 8:24 PM, Gary Mohr <gary.m...@bull.com> wrote:
>
> Stephane,
>
>
>
> Attached is a libpfm4 patch for Intel x86 systems to export the constraint
> masks when doing a pfm_get_event_info() call. With this change, I have
> been able to get the papi_native_avail tool to show the counter constraints
> at both the event and umask level. I currently works for core events but
> not for uncore events.
>
>
>
> I wanted to pass this by you to see if it satisfies your “portable and
> backward compatible” requirements.
>
> If so I will extend it to also handle the Intel uncore events.
>
>
>
> The patch is okay except for one thing. It breaks the ABI.
>
> An existing program linked with libpfm.so.4 will break when
>
> likned against your version. The cntmsk field is where there
>
> was something else before.
>
> You need to change the ABI rev and handle programs linked
>
> with ABI0.
>
>
>
>
>
> One other question. I have been able to get PAPI to use
> “PFM_OS_PERF_EVENT_EXT” to get support for the cpu mask provided with this
> mode. When this effort was started you provided me with a libpfm4 patch
> file (copy attached) which looks like it adds the cpu mask to the this
> mode. It appears to me like this patch is not yet committed to the head of
> your GIT. Will you be able to commit this patch so that the next time PAPI
> pulls a new libpfm4, the cpu mask will be included in the extended mode.
>
>
>
> Thanks
>
> Gary
>
>
>
> My todo list has one other thing that may affect libpfm4. I would like be
> able to create an event list which includes the counter register
> constraints for the events and/or umasks (when there are constraints). I
> see the information already exists in the libpfm4 event tables, but I see
> no way to get the information back from libpfm4. Perhaps these values
> could be added as a new field in the information structures returned from
> the pfm_get_event_info and pfm_get_attr_info function calls.
>
>
>
> There is currently no way to extract that constraint mask. If it were
> implemented it would be via the existing pfm_get_event_info() call. I'd
> like to avoid
>
> adding yet another call just for that.
>
> The reason it is not yet exposed is because nowadays on Linux it is
> irrelevant because ultimately controlled by the kernel.
>
> Even though the user could know, it would have only a small influence on
> the actual scheduling, except on a single user
>
> machine.
>
>
>
> Exposing this also assumes that the constraints can always be expressed as
> a simple bitmask. Some events have more dynamic constraints
>
> which depend on what is measured on the other sibling CPUs for instance
> (offcore_response_* events).
>
>
>
> I agree though that the info could help with grouping of events, should
> you need this for some measurements.
>
>
>
>
>
>
>
> It would be nice if the user could see the counter constraints without
> having to go find the intel/amd/??? manuals. I understand that the counter
> constraints are actually enforced by the kernel and not libpfm4 but being
> able to provide this information to the user would help them determine
> which events can be used together. With the newer kinds of hardware,
> counter constraints are becoming more common so I think additional help for
> the user in this area is a good idea.
>
>
>
> Thoughts ??
>
>
>
> Make a patch proposal to add this.
>
> Needs to be portable and backward compatible with what is already there.
>
>
>
>
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
