Hi Stefane,
Thanks. This is much clearer.
Given the below, I do want pfm_arch_start to call pfm_restore_pmcs but
it should do a little bit more. The difference isn't in the core's
PMU, but the external PMU (the SCB). pfm_restore_pmcs will always
write all the PMC values for both, enabling counting by twiddling
domain bits in the core's PMC's and the event bits in the external
PMU's PMC's. However, pfm_arch_start will write the enable bit for the
external PMU and leave it on until that process (and other processes)
finish using it (via an atomic refcnt that gets tracked with a PMC
write checker). That bit will only be cleared in arch_unload_context
if appropriate.
This should simplify our code greatly, as well as reduce the locking
and critical sections that are there.
Regards,
Phil
On Mar 25, 2008, at 1:13 PM, stephane eranian wrote:
> Phil,
>
>
> On Tue, Mar 25, 2008 at 4:55 PM, Philip Mucci <[EMAIL PROTECTED]>
> wrote:
>> Hi Stefane,
>>
>> Thanks for this. Am I to understand that the original purpose of
>> pfm_arch_start is to just flip the enable bits? Is counting supposed
>> to be enabled after arch_restore_pmcs? My question is really, what is
>> the counting state of the PMU supposed to be after restore? I read
>> the
>> below as restore is supposed to write+start the PMC's immediately.
>>
> pfm_arch_start() is used to enable monitoring. Unfortunately, this
> term
> is too vague. There are vast differences in how you accomplish this
> across
> architectures.
>
> On IA-64, enable monitoring does not actually require touching the
> PMU registers, but just a Processor Status Register (PSR). The
> register
> is part of the *generic* machine state. The value of the PMU control
> bit
> inside the PSR is saved/restored on PMU ctxsw. Thus we need to
> bootstrap
> by initializing the value so it can be picked up on first context
> switch in.
> Note that on IA-64, there is something to do in pfm_arch_start()
> regardless
> of whether we are working on the current thread or not.
>
> On X86, to enable monitoring, means to turn on at least one of the
> plm bits.
> That means the PMC registers need to be written. But this is
> necessary ONLY
> if working on the current thread. for non-self, this is all handled by
> the context switch
> in routine. There maybe other things to activate for self-monitoring
> such as PEBS/DS
> support. Until started, the actual PMC registers never get written by
> pfm_write_pmcs(),
> nor the context switch in routine. In a sense, most of what
> pfm_arch_start() does on X86,
> is also done by pfm_arch_restore_pmcs().
>
>
> Hope this helps a bit.
>
>
>> It's an interesting case on the SiCortex box, because the in-core
>> PMU's have no enable bits (only domain bits) but the off-core PMU has
>> a global enable bit, which need not be twiddled, as one can write 0's
>> to the PMC's there and it won't count.
>>
>> Thanks.
>>
>> Phil
>>
>>
>>
>> On Mar 24, 2008, at 6:03 PM, stephane eranian wrote:
>>
>>> Hello Phil,
>>>
>>> pfm_arch_start() is not called during context switch. It is used
>>> only
>>> during pfm_start() and on interrupts on certain architectures.
>>>
>>> pfm_restore_pmcs() is used on context switch to restore the pmcs
>>> (config) registers.
>>>
>>> If all pfm_arch_start() does is to restore the pmcs, then it may as
>>> well
>>> call pfm_arch_restore_pmcs() instead of re-implementing the same
>>> thing.
>>>
>>>
>>>
>>> On Mon, Mar 24, 2008 at 8:17 PM, Philip Mucci <[EMAIL PROTECTED]>
>>> wrote:
>>>> Hi Stefane,
>>>>
>>>> I'm trying to decipher the difference between these two.
>>>> Currently on
>>>> MIPS as there is no enable bit, these are both identical.
>>>> Basically:
>>>>
>>>> for (i = 0; i < max_pmc; i++) {
>>>> if (test_bit(i, set->used_pmcs))
>>>> pfm_arch_write_pmc(ctx, i, set->pmcs[i]);
>>>> }
>>>>
>>>> However, in looking at the comments in the code, I have a concern
>>>> that
>>>> they may both be being called on pfm_ctxsw() and thus I'm doing
>>>> double
>>>> writes to the registers. Can you comment on this?
>>>>
>>>> Phil
>>>>
>>>>
>>
>>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
