Corey,
On Wed, Sep 24, 2008 at 1:07 AM, Corey Ashford <[EMAIL PROTECTED]> wrote:
> A few comments/questions below:
>
> "stephane eranian" <[EMAIL PROTECTED]> wrote on 09/23/2008 02:32:24 PM:
> > 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?
>
That is correct. There will be no sampling at all in the first patch. We want
to really focus on the core and key-value add (per-thread counting).
> >
> > 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?
>
Yes.
> 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?
>
This is an interesting question. In the current proposal, pfarg_pmd_attr
is specifically meant for PMD registers. If is ignored for PMC registers.
Should we need to add a new type, let's call it FOO, then we would
add a new flag PFM_RWFL_FOO, we would still use the pfarg_pmr_t
structure for the basic description. Then if FOO needs some extra, we
would add another parameter after pfarg_pmd_attr, it would be called
pfarg_foo_attr. You would call as follows:
pfm_write_pmrs(fd, PFM_RWFL_FOO, pmrs, 1, NULL, foo);
Now if we generalize pfarg_pmd_attr and call it pfarg_pmr_attr, then we could
leverage the reserved fields. We would still need the PFM_RWFL_FOO and
it would cause the kernel to only pick at the new fields in pfarg_pmr_attr.
> > New structures:
> > 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?
>
Yes.
> >
> > 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?
>
If you use the attributes then yes, you copy exactly the same as with v2.81.
But the nice thing is that you don't have to pass them if you don't need them.
You can call as follows:
pfm_write_pmrs(fd, PFM_RWFL_PMD, pmrs, 1);
And with attributes:
pfm_write_pmrs(fd, PFM_RWFL_PMD_ATTR, pmrs, 1, pmas);
There is the assumption that the pmas vector is as big as the pmrs vector, so we
can avoid having a count for pmas.
> >
> > 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?
>
Just like it is today. This is based on the type of the session (context).
I only showed the new flags in pfm_create_session. The PFM_FL_SYSTEM_WIDE
flag still exists.
>
> > V) event set and multiplexing
>
> 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?
>
Correct.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
perfmon2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
