Hello,
Here are two concerns about this new v3.0 and especially about the
lightweight version
which is what we will be starting with.
The first issue is about the pfarg_pmr sructure which is defined as follows:
> typedef struct {
> u16 reg_num;
> u16 reg_set;
> u32 reg_flags;
> u64 reg_value;
> } pfarg_pmr_t;
>
It is used for both PMD and PMC. It currently has a very nice size of
16 bytes but it does not have room
for extensions. Yet, I felt it was pretty complete to describe a
register. Extended attributes for PMD are
all located in the pfarg_pmd_attr structure. So far, we never had a
need for PMC attributes beyond flags.
We could extend this struct with 2 8-byte reserved fields to keep a
nice size. That would double the
size of the struct, though.
The second issue is about the lightweight patch for v3.0. It only
provides support for counting on a per-thread
basis. Thus, there is no pfm_getinfo_sets().
What's the problem?
Well, this call is used to figure out which registers are actually
available to the session. It is important for tools
and libpfm because they use this information to work-around
unavailable registers. For instance, on X86, if the
NMI watchdog is enabled, it uses one counter and runs concurrently
with perfmon. Thus, libpfm needs to ignore
this register when it assigns events to counters. The information is
provided by getinfo() even though it is currently
global to a session. It is per-set today because I did not want to add
yet another syscall just for this. Using this
syscall is useful because it can be queried at anytime during the
lifetime of the session.
Another possibility would have been to return this when the session
gets created with pfm_create_session().
It would be another parameter. Of course, it would disappear from
pfarg_setinfo(). But then it implies that
this information could not change during the lifetime of the session.
For instance, if the NMI were to release
its counter, we would not be able to use it right away, we would have
to destroy the context and recreate one.
Of course, we can always leave things as they are and say that bitmask
of available registers will only come
when we add event sets and multiplexing support.
Any opinions on these issues?
On Tue, Sep 23, 2008 at 11:32 PM, stephane eranian
<[EMAIL PROTECTED]> wrote:
> 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
>
> II) programming the registers
>
> 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);
>
> New structures:
>
> V) event set and multiplexing
> 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);
-------------------------------------------------------------------------
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
