* perf lock usage
@ 2014-01-23 6:49 Sujith Manoharan
2014-01-23 12:36 ` Frederic Weisbecker
2014-01-28 9:35 ` Jiri Olsa
0 siblings, 2 replies; 6+ messages in thread
From: Sujith Manoharan @ 2014-01-23 6:49 UTC (permalink / raw)
To: linux-perf-users
Hi,
I am trying to use perf lock and am not sure if
the results are correct (the bad rate is 98 %).
Is this expected behavior ?
root@linux-test ~# perf --version
perf version 3.12.0
root@linux-test ~# perf lock record cat /etc/issue
Arch Linux \r (\l)
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.356 MB perf.data (~15533 samples) ]
root@linux-test ~# perf lock report
Name acquired contended total wait (ns) max wait (ns) min wait (ns)
&cpuctx_lock 0 0 0 0 0
&sig->cred_guard... 0 0 0 0 0
=== output for debug===
bad: 153, total: 155
bad rate: 98.709677 %
histogram of events caused bad sequence
acquire: 1
acquired: 0
contended: 0
release: 152
I am using the wireless-testing kernel:
root@linux-test ~# uname -a
Linux linux-test 3.13.0-wl-debug #197 SMP PREEMPT Tue Jan 21 03:19:43 IST 2014 x86_64 GNU/Linux
lockdep is enabled:
root@linux-test ~# zgrep -i lockdep /proc/config.gz
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
Sujith
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: perf lock usage
2014-01-23 6:49 perf lock usage Sujith Manoharan
@ 2014-01-23 12:36 ` Frederic Weisbecker
2014-01-23 12:37 ` Sujith Manoharan
2014-01-28 9:35 ` Jiri Olsa
1 sibling, 1 reply; 6+ messages in thread
From: Frederic Weisbecker @ 2014-01-23 12:36 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: perf group
2014/1/23 Sujith Manoharan <sujith@msujith.org>:
> Hi,
>
> I am trying to use perf lock and am not sure if
> the results are correct (the bad rate is 98 %).
>
> Is this expected behavior ?
>
> root@linux-test ~# perf --version
> perf version 3.12.0
>
> root@linux-test ~# perf lock record cat /etc/issue
> Arch Linux \r (\l)
>
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.356 MB perf.data (~15533 samples) ]
> root@linux-test ~# perf lock report
> Name acquired contended total wait (ns) max wait (ns) min wait (ns)
>
> &cpuctx_lock 0 0 0 0 0
> &sig->cred_guard... 0 0 0 0 0
>
> === output for debug===
>
> bad: 153, total: 155
> bad rate: 98.709677 %
> histogram of events caused bad sequence
> acquire: 1
> acquired: 0
> contended: 0
> release: 152
>
> I am using the wireless-testing kernel:
> root@linux-test ~# uname -a
> Linux linux-test 3.13.0-wl-debug #197 SMP PREEMPT Tue Jan 21 03:19:43 IST 2014 x86_64 GNU/Linux
>
> lockdep is enabled:
> root@linux-test ~# zgrep -i lockdep /proc/config.gz
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_LOCKDEP=y
> # CONFIG_DEBUG_LOCKDEP is not set
>
Hi Sujith,
You also need CONFIG_LOCK_STAT=y
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: perf lock usage
2014-01-23 12:36 ` Frederic Weisbecker
@ 2014-01-23 12:37 ` Sujith Manoharan
0 siblings, 0 replies; 6+ messages in thread
From: Sujith Manoharan @ 2014-01-23 12:37 UTC (permalink / raw)
To: Frederic Weisbecker; +Cc: perf group
Frederic Weisbecker wrote:
> > lockdep is enabled:
> > root@linux-test ~# zgrep -i lockdep /proc/config.gz
> > CONFIG_LOCKDEP_SUPPORT=y
> > CONFIG_LOCKDEP=y
> > # CONFIG_DEBUG_LOCKDEP is not set
>
> Hi Sujith,
>
> You also need CONFIG_LOCK_STAT=y
CONFIG_LOCK_STAT is enabled too.
root@linux-test ~# zgrep -i lock_stat /proc/config.gz
CONFIG_LOCK_STAT=y
Sujith
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: perf lock usage
2014-01-23 6:49 perf lock usage Sujith Manoharan
2014-01-23 12:36 ` Frederic Weisbecker
@ 2014-01-28 9:35 ` Jiri Olsa
2014-01-29 13:53 ` Sujith Manoharan
1 sibling, 1 reply; 6+ messages in thread
From: Jiri Olsa @ 2014-01-28 9:35 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: linux-perf-users
On Thu, Jan 23, 2014 at 12:19:56PM +0530, Sujith Manoharan wrote:
> Hi,
>
> I am trying to use perf lock and am not sure if
> the results are correct (the bad rate is 98 %).
>
> Is this expected behavior ?
some of the kernel lock types do not follow the:
acquire
contended
acuired
release
lock state machine, like rcu or spin locks.. and thats what
caused most of the bad rates in my tests.
I was recently working on some changes for lock tracing,
what stats are you interested in?
jirka
>
> root@linux-test ~# perf --version
> perf version 3.12.0
>
> root@linux-test ~# perf lock record cat /etc/issue
> Arch Linux \r (\l)
>
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.356 MB perf.data (~15533 samples) ]
> root@linux-test ~# perf lock report
> Name acquired contended total wait (ns) max wait (ns) min wait (ns)
>
> &cpuctx_lock 0 0 0 0 0
> &sig->cred_guard... 0 0 0 0 0
>
> === output for debug===
>
> bad: 153, total: 155
> bad rate: 98.709677 %
> histogram of events caused bad sequence
> acquire: 1
> acquired: 0
> contended: 0
> release: 152
>
> I am using the wireless-testing kernel:
> root@linux-test ~# uname -a
> Linux linux-test 3.13.0-wl-debug #197 SMP PREEMPT Tue Jan 21 03:19:43 IST 2014 x86_64 GNU/Linux
>
> lockdep is enabled:
> root@linux-test ~# zgrep -i lockdep /proc/config.gz
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_LOCKDEP=y
> # CONFIG_DEBUG_LOCKDEP is not set
>
>
> Sujith
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: perf lock usage
2014-01-28 9:35 ` Jiri Olsa
@ 2014-01-29 13:53 ` Sujith Manoharan
2014-01-30 10:33 ` Jiri Olsa
0 siblings, 1 reply; 6+ messages in thread
From: Sujith Manoharan @ 2014-01-29 13:53 UTC (permalink / raw)
To: Jiri Olsa; +Cc: linux-perf-users
Jiri Olsa wrote:
> some of the kernel lock types do not follow the:
> acquire
> contended
> acuired
> release
>
> lock state machine, like rcu or spin locks.. and thats what
> caused most of the bad rates in my tests.
>
> I was recently working on some changes for lock tracing,
> what stats are you interested in?
I am trying to see lock usage stats for the ath9k wireless driver.
Mainly in the transmission path, where normal spin locks
are acquired.
Sujith
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: perf lock usage
2014-01-29 13:53 ` Sujith Manoharan
@ 2014-01-30 10:33 ` Jiri Olsa
0 siblings, 0 replies; 6+ messages in thread
From: Jiri Olsa @ 2014-01-30 10:33 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: linux-perf-users
On Wed, Jan 29, 2014 at 07:23:57PM +0530, Sujith Manoharan wrote:
> Jiri Olsa wrote:
> > some of the kernel lock types do not follow the:
> > acquire
> > contended
> > acuired
> > release
> >
> > lock state machine, like rcu or spin locks.. and thats what
> > caused most of the bad rates in my tests.
> >
> > I was recently working on some changes for lock tracing,
> > what stats are you interested in?
>
> I am trying to see lock usage stats for the ath9k wireless driver.
> Mainly in the transmission path, where normal spin locks
> are acquired.
I was using following code for studying the lock flow,
but it can also display the overhead (but not much in detail)
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
perf/core_lock branch
the usage is sort of described in example here:
https://git.kernel.org/cgit/linux/kernel/git/jolsa/perf.git/commit/?h=perf/core_lock&id=f140425e46b2469b825c12b72507c6f3c539c7dd
so far I've been using the list mode only for checking
the lock flow, but it doesn't seem much useful otherwise..
so I haven't shared it yet
not sure this can be any use for you, but let me know if
you'd need other info
jirka
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-01-30 10:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-23 6:49 perf lock usage Sujith Manoharan
2014-01-23 12:36 ` Frederic Weisbecker
2014-01-23 12:37 ` Sujith Manoharan
2014-01-28 9:35 ` Jiri Olsa
2014-01-29 13:53 ` Sujith Manoharan
2014-01-30 10:33 ` Jiri Olsa
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).