"stephane eranian" <[EMAIL PROTECTED]> wrote on 10/01/2008 06:56:58 
AM:

> 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.

It might be a good idea to have a couple of reserved fields available in 
case you want to introduce new fields that are common to pmds and pmcs. 
Hard to imagine what they would be, but you won't know till you want them! 
 Then again, even two fields may not be enough.  It's a gamble either way.

> 
> 
> 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.

a) How likely is it that the counter used for the watchdog would be 
released while someone is using perfmon?  b) in the event that it is 
released, how big of an impact is destroying and recreating a context?  I 
would guess that a is very unlikely, and b is not that large of an impact.

Does perfmon have to "allocate" the counter normally used for NMI watchdog 
from the OS?  Does the OS then wait on some sort of lock to allocate it 
when it wants to use it?

> 
> 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.

Without the bitmask, could a user accidentally claim access to a register 
currently being used by the OS or some other app?  That would be bad.

Regards,

- Corey


Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR 
503-578-3507 
[EMAIL PROTECTED]


-------------------------------------------------------------------------
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
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to