On Tue, Aug 4, 2009 at 11:05 PM, Tanima Dey<[email protected]> wrote:
> Hi,
> I am sorry I missed it.
> I actually wanted to know the approximate difference between the summation
> of per-thread counters' values and the system-wide value. Are there any
> other ways to know it?

I am assuming you are measuring at both user+kernel levels, right?

In that case difference should be minimum because PMU state is saved
and restored
at the very core of the lowest-level context switch code, i.e.,
monitoring is really stopped
at the last minute. Then, the next thing the kernel does is reload the
PMU state for the
next thread if it uses the PMU.

> Thanks
> Tanima.
> ________________________________
> From: stephane eranian <[email protected]>
> To: Tanima Dey <[email protected]>
> Cc: Perfmon <[email protected]>
> Sent: Tuesday, August 4, 2009 4:00:53 PM
> Subject: Re: [perfmon2] Counters' value perthread/systemwide
>
> On Tue, Aug 4, 2009 at 7:00 PM, Tanima Dey<[email protected]> wrote:
>> Hi,
>> No I am using the same perfmon2 tool and in the same program I am both
>> per-thread and system-wide context. Is it possible?
>
> No it's not. But you did not tell why you think that's needed for what you
> want
> to do. there may be another way of doing this.
>
>
>> Thanks
>> Tanima.
>>
>> ________________________________
>> From: stephane eranian <[email protected]>
>> To: Tanima Dey <[email protected]>
>> Cc: Perfmon <[email protected]>
>> Sent: Tuesday, August 4, 2009 11:47:25 AM
>> Subject: Re: [perfmon2] Counters' value perthread/systemwide
>>
>> Hi,
>>
>> On Tue, Aug 4, 2009 at 5:32 PM, Tanima Dey<[email protected]> wrote:
>>>
>>> Hi,
>>> I got the answer to my previous question. In my case, system-wide and
>>> per-thread monitoring session is not co-existent. Is it always the case?
>>> I
>>> got from a documentation that such determination of co-existence is
>>> possible
>>> when the context is attached, not when it is created. Can anyone tell me
>>> how
>>> to do it?
>>>
>> System-wide and per-thread context cannot co-exist in the current
>> implementation.
>> The only reason for doing this is if you have two distinct tools
>> competing for the PMU.
>> Is that your case?
>>
>>
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
perfmon2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to