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:
>
>> 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.
>
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.
>> 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.
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 counters only 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.
-------------------------------------------------------------------------
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
