Thanks for the replay.
"stephane eranian" <[EMAIL PROTECTED]> wrote on 10/01/2008 01:07:29
PM:
> Corey,
>
> On Wed, Oct 1, 2008 at 8:24 PM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > "stephane eranian" <[EMAIL PROTECTED]> wrote on 10/01/2008
06:56:58
> > AM:
<snip>
> >
> > 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.
> >
>
> Well, there is always the possibility to add a new parameter to the
> calls, i.e., an
> overflow structure, like we do with pfarg_pmd_attr. The flags are here to
help
> with that at the syscall level.
Good point; that provides another upgrade route.
>
> >> 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?
> >
> If the counter is used by another subsystem, you won't be able to access
it.
>
> The current logic is that when the first session is created perfmon
allocates
> all the registers it finds using a lower-level MSR allocator
> (perfctr-watchdog.c).
> Until the last perfmon session, perfmon has control over those registers.
When
> the last context terminates, the registers are released to the
> allocator. This is
> done this way to provide some level of guarantee to applications. Of
course,
> within perfmon we can divide the registers either way we want. For
instance,
> we may want to split them up between system-wide and per-thread, to allow
> both types of sessions to run concurrently wherever the hardware permits.
> But again, I think the reasonable usage model is that on creation,
perfmon
> tells you what you have available and it does not change from underneath
> until you destroy your session. Otherwise, applications have to adopt the
> try & retry model, i.e., try using some registers, if that fails,
> query the new
> set of registers, assign events to those registers and try, and so on.
It's a bit different on Power where we have just a single "ownership" flag
which says all of the PMU regs are being used or not.
>
> I think many applications, including pfmon, are structured such that
> you query once,
> you then dispatch events to counters via libpfm and then you create
> the session(s),
> program the registers, attach to a thread or CPU and start. As you can
> see, pfmon,
> does not even fit the model, I'd have to dispatch events to countersonly
AFTER
> the context is created, i.e., once I get the info about what is
> available. Today, pfmon
> cheats, it creates a fake context just to retrieve the data, and then
> it destroy it
> assuming the registers won't change. Changing that would be difficult.
> Take system-wide,
> we create as many sessions as they are CPU(s) by default. If you were
> to defer assigning
> events to counters, you'd have to repeat that operation for each
> context instead of doing
> it once and using the output for each session.
>
> I have not looked at the internals of PAPI, so I don't know if they
> query the list of available
> registers to pass to libpfm.
>
> >>
> >> 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.
>
> No, the OS always check what is actually available.
I see. Thanks.
- 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
