* Doubt about cache coherence related perf event
@ 2012-02-25 4:05 Joy James Prabhu
2012-02-27 3:39 ` David Ahern
0 siblings, 1 reply; 3+ messages in thread
From: Joy James Prabhu @ 2012-02-25 4:05 UTC (permalink / raw)
To: linux-perf-users
I am working on monitoring cache coherence events using perf. The more I use
the tool, the more I appreciate its design :)
So, I am using perf on Intel i7 Nehalem machine which supports this event
related to L1 data cache stores :
#-----------------------------
IDX : 31457325
PMU name : nhm (Intel Nehalem)
Name : L1D_CACHE_ST
Equiv : None
Flags : None
Desc : L1 data cache stores
Code : 0x41
Umask-00 : 0x04 : PMU : [E_STATE] : None : L1 data cache stores in E state
Umask-01 : 0x01 : PMU : [I_STATE] : None : L1 data cache store in the I state
Umask-02 : 0x08 : PMU : [M_STATE] : None : L1 data cache stores in M state
Umask-03 : 0x02 : PMU : [S_STATE] : None : L1 data cache stores in S state
Umask-04 : 0x0f : PMU : [MESI] : [default] : L1 data cache store in all states
To obtain these events, I used the command :
"perf -R -e r141:u,r241:u,r441:u,r841:u -c 3 <some binary>"
(a) Now, just to be sure, are my raw event identifiers correct ?
(b) I then used "perf script" on the perf.data file, but here comes the strange
part :
I got this log tuple for 'pbzip2_good' binary using r841:u [ L1 data cache
stores in modified state at user level ] :
pbzip2_good 5857 [004] 15198.792535: raw 0x841: 402c1c
_Z19consumer_decompressPv
(/home/joy/Desktop/Perf/pbzip2/pbzip2-0.9.4/pbzip2_good)
Basically, it points to an instruction 402c1c in consumer_decompress
function which is basically a call to pthread_mutex_lock :
/home/joy/Desktop/Perf/pbzip2/pbzip2-0.9.4/pbzip2.cpp:555
402c18: 48 8b 7b 30 mov 0x30(%rbx),%rdi
402c1c: e8 87 ed ff ff callq 4019a8 <pthread_mutex_lock@plt>
Corresponding code :
pthread_mutex_lock(fifo->mut);
So, I was expecting "402c18" to be the interesting instruction, but I always
see the "402c1c" instruction in the perf log. I see several more
pthread_function calls in the log.
How can a "call" instruction, which from my understanding, has nothing to do
with cache coherence events in data cache, always come up in the output ? While
the "mov" instruction, which is more related to modified stores in data cache,
never comes up in the log.
All suggestions are welcome :)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Doubt about cache coherence related perf event
2012-02-25 4:05 Doubt about cache coherence related perf event Joy James Prabhu
@ 2012-02-27 3:39 ` David Ahern
2012-02-27 18:15 ` Joy James Prabhu Arulraj
0 siblings, 1 reply; 3+ messages in thread
From: David Ahern @ 2012-02-27 3:39 UTC (permalink / raw)
To: Joy James Prabhu; +Cc: linux-perf-users
On 2/24/12 9:05 PM, Joy James Prabhu wrote:
> I am working on monitoring cache coherence events using perf. The more I use
> the tool, the more I appreciate its design :)
>
> So, I am using perf on Intel i7 Nehalem machine which supports this event
> related to L1 data cache stores :
>
> #-----------------------------
> IDX : 31457325
> PMU name : nhm (Intel Nehalem)
> Name : L1D_CACHE_ST
> Equiv : None
> Flags : None
> Desc : L1 data cache stores
> Code : 0x41
> Umask-00 : 0x04 : PMU : [E_STATE] : None : L1 data cache stores in E state
> Umask-01 : 0x01 : PMU : [I_STATE] : None : L1 data cache store in the I state
> Umask-02 : 0x08 : PMU : [M_STATE] : None : L1 data cache stores in M state
> Umask-03 : 0x02 : PMU : [S_STATE] : None : L1 data cache stores in S state
> Umask-04 : 0x0f : PMU : [MESI] : [default] : L1 data cache store in all states
>
> To obtain these events, I used the command :
> "perf -R -e r141:u,r241:u,r441:u,r841:u -c 3<some binary>"
>
>
> (a) Now, just to be sure, are my raw event identifiers correct ?
>
> (b) I then used "perf script" on the perf.data file, but here comes the strange
> part :
>
> I got this log tuple for 'pbzip2_good' binary using r841:u [ L1 data cache
> stores in modified state at user level ] :
>
> pbzip2_good 5857 [004] 15198.792535: raw 0x841: 402c1c
> _Z19consumer_decompressPv
> (/home/joy/Desktop/Perf/pbzip2/pbzip2-0.9.4/pbzip2_good)
>
> Basically, it points to an instruction 402c1c in consumer_decompress
> function which is basically a call to pthread_mutex_lock :
>
> /home/joy/Desktop/Perf/pbzip2/pbzip2-0.9.4/pbzip2.cpp:555
> 402c18: 48 8b 7b 30 mov 0x30(%rbx),%rdi
> 402c1c: e8 87 ed ff ff callq 4019a8<pthread_mutex_lock@plt>
>
> Corresponding code :
>
> pthread_mutex_lock(fifo->mut);
>
> So, I was expecting "402c18" to be the interesting instruction, but I always
> see the "402c1c" instruction in the perf log. I see several more
> pthread_function calls in the log.
>
> How can a "call" instruction, which from my understanding, has nothing to do
> with cache coherence events in data cache, always come up in the output ? While
> the "mov" instruction, which is more related to modified stores in data cache,
> never comes up in the log.
>
> All suggestions are welcome :)
I believe it is called skid. A recent thread about it:
http://comments.gmane.org/gmane.linux.kernel/1244502
David
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Doubt about cache coherence related perf event
2012-02-27 3:39 ` David Ahern
@ 2012-02-27 18:15 ` Joy James Prabhu Arulraj
0 siblings, 0 replies; 3+ messages in thread
From: Joy James Prabhu Arulraj @ 2012-02-27 18:15 UTC (permalink / raw)
To: linux-perf-users
David, thanks for pointing me to the relevant post :)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-02-27 18:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-25 4:05 Doubt about cache coherence related perf event Joy James Prabhu
2012-02-27 3:39 ` David Ahern
2012-02-27 18:15 ` Joy James Prabhu Arulraj
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.