linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joy James Prabhu <prabhu.link@gmail.com>
To: linux-perf-users@vger.kernel.org
Subject: Doubt about cache coherence related perf event
Date: Sat, 25 Feb 2012 04:05:44 +0000 (UTC)	[thread overview]
Message-ID: <loom.20120225T050202-879@post.gmane.org> (raw)

 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 :)

             reply	other threads:[~2012-02-25  4:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-25  4:05 Joy James Prabhu [this message]
2012-02-27  3:39 ` Doubt about cache coherence related perf event David Ahern
2012-02-27 18:15   ` Joy James Prabhu Arulraj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20120225T050202-879@post.gmane.org \
    --to=prabhu.link@gmail.com \
    --cc=linux-perf-users@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).