Re: [perfmon2] perfmon3 interface overview
Status: Beta
Brought to you by:
seranian
From: Corey A. <cja...@us...> - 2008-09-23 23:08:04
|
A few comments/questions below: "stephane eranian" <er...@go...> wrote on 09/23/2008 02:32:24 PM: [snip] > Here are the details: > > I) session creation > > With v2.81: > int pfm_create_context(pfarg_ctx_t *ctx, char *smpl_name, void > *smpl_arg, size_t smpl_size); > > With v3.0: > int pfm_create_session(int flags); > int pfm_create_session(int flags, char *smpl_name, void > *smpl_arg, size_t smpl_size); > > New Flags: > PFM_FL_SMPL_FMT : indicate using sampling format and > that 3 additional parameters are passed I assume custom sampling buffers are not going to be supported in the first LKML posting of 3.0. Is that still true? > > The pfarg_ctx_t structure has been abandoned. The flags parameter is > used very much like for the open(2) > syscall to indicate that additional (optional) parameters are passed. > > All old flags are preserved. > > The call still returns the file descriptor uniquely identifying > the session. > > Just like with context, a session can either be monitoring a > thread or a CPU. > > II) programming the registers > > With v2.81: > int pfm_write_pmcs(int fd, pfarg_pmc_t *pmds, int n); > int pfm_write_pmds(int fd, pfarg_pmd_t *pmcs, int n); > int pfm_read_pmds(int fd, parg_pmd_t *pmds, int n); > > With v3.0: > int pfm_write_pmrs(int fd, int flags, pfarg_pmr_t *pmrs, int n); > int pfm_write_pmrs(int fd, int flags, pfarg_pmr_t *pmrs, int n, > pfarg_pmd_attr_t *pmas); > > int pfm_read_pmrs(int fd, int flags, pfarg_pmr_t *pmrs, int n); > int pfm_read_pmrs(int fd, int flags, parg_pmr_t *pmrs, int n, > pfarg_pmd_attr_t *pmas); > The 'a' in pma stands for "attributes" I assume? Chances are unlikely for it to actually happen, but what if, in the future, you found you need to add another register type, with its own attributes? Would the type of the final parameter be different? Should that maybe be a "void *pmas" instead, or is using "void *" seriously frowned upon in kernel circles? > New structures: > > typedef struct { > u16 reg_num; > u16 reg_set; > u32 reg_flags; > u64 reg_value; > } pfarg_pmr_t; > > typedef struct { > u64 reg_long_reset; > u64 reg_short_reset; > u64 reg_random_mask; > u64 reg_smpl_pmds[PFM_PMD_BV]; > u64 reg_reset_pmds[PFM_PMD_BV]; > u64 reg_ovfl_swcnt; > u64 reg_smpl_eventid; > u64 reg_last_value; > u64 reg_reserved[8]; > }; pfarg_pmd_attr_t is the above struct, right? > > New flags: > PFM_RWFL_PMD : pmrs contains PMD register descriptions > PFM_RWFL_PMC : pmrs contains PMC register descriptions > PFM_RWFL_PMD_ATTR: an additional vector is passed in pmas > > We now use only 2 system calls to read and write the PMU registers. > This is possible because > we are sharing the same register description data structure, > pfarg_pmr_t. They key attributes > of each register are encapsulated into this structure. Additional > PMD attributes related to sampling > and multiplexing are off-loaded into another optional structure, > pfarg_pmd_attr_t. This structure > becomes optional and is only looked at by the kernel if the > PFM_RWFL_PMD_ATTR flag is passed. > > For all counting applications, using pfarg_pmr_t is enough. The nice > side effect of this split is that > the cost of reading and writing PMD register is now reduced because > we have less data to copy in > and out of the kernel. The amount of data copied to and from the kernel for pmd read/write the same as in 2.81, right? > > Unlike suggested by some people, I have not merged the notions of > PMD and PMC registers. I think > it is cleaner to separate them out. It also makes it much easier to > provide backward compatibility with > v2.81. > > III) attaching and detaching > > With v2.81: > int pfm_load_context(int fd, pfarg_load_t *load); > int pfm_unload_context(int fd); > > With v3.0: > int pfm_attach_session(int fd, int flags, int target); > int pfm_detach_session(int fd, int flags); > > The pfarg_load_t structure has been abandoned. The information > about what to > attach to is passed as a parameter to the syscall in "target". It > can either be > a thread id or a CPU id. How is a CPU id distinguished from a thread id? > > There are currently no flags defined for either call. Maybe need a flag to distinguish CPU ids from thread ids? > > Note that we have lost the ability to specify which event set is > to be activated first. > There was no actual use of this option anyway. > [snip] > V) event set and multiplexing > > With v2.81: > int pfm_create_evtsets(int fd, pfarg_setdesc_t *s, int n); > int pfm_getinfo_evtsets(int fd, pfarg_setinfo_t *s, int n); > int pfm_delete_evtsets(int fd, pfarg_setdesc_t *s, int n); > > With v3.0: > int pfm_create_sets(int fd, int flags, pfarg_setdesc_t *s, int n); > int pfm_getinfo_evtsets(int fd, int flags, pfarg_setinfo_t > *s, int n); > Just so I'm clear, the event set and multiplexing interface is not going to be part of the first perfmon3.0 posting to LKML, right? > VII) conclusions > > There are no other modifications to other parts of the API. > > I think this ultimate modification addresses ALL outstanding > issues raised by LKML. > > I have presented the new API for a fully featured perfmon, with > sampling, system-wide and multiplexing. > This is not what is going to go into the mainline kernel > initially. The plan is to use this as the development > code and pull bits and pieces into the minimal kernel patch that > I maintain separately and which is > what I intend to post to LKML. The reason I modified the fully > featured version is to gauge all the changes > needed and their potential connections. Good plan. > > I will soon, create branches on both the GIT tree, libpfm CVS so > that you will be able to experiment with this > API. The v3.0 has been added to all architectures currently > supported. They all compile. I was not able to > tests many of them for lack of hardware. That's great! > > I welcome any comments you may have about this new API. > > S.Eranian > > Thanks. > - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 cja...@us... |