From: Peter Zijlstra <peterz@infradead.org>
To: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: Question about lock sequence
Date: Sat, 10 Apr 2010 16:01:51 +0200 [thread overview]
Message-ID: <1270908111.4222.4.camel@twins> (raw)
In-Reply-To: <4BC05677.7070406@dcl.info.waseda.ac.jp>
On Sat, 2010-04-10 at 19:44 +0900, Hitoshi Mitake wrote:
> Hi,
>
> I found that my understand about lockdep is completely wrong :( ,
> so state machine of perf lock should be fixed before optimization.
>
> And I found that behaviour related to some of spin locks are strange.
> The concrete example is lock sequences targeting dcache_lock (defined in
> head of fs/dcache.c).
>
> I made a little (and not essential) change to perf lock, and observe
> lock sequence targeting it.
> Changed perf lock shows sequence of locks in time order,
> and I grepped the output of it with dcache, like this:
>
> % sudo ./perf lock report | grep dcache
>
> The head part of result is this:
> # <name>-<pid> <time (in u64)> <action> <address of lockdep> <name of lock>
> perf-3238 92430534170 acquire: 0xffffffff81a4b398 dcache_lock
> perf-3238 92430536714 acquire: 0xffffffff81a4b398 dcache_lock
> perf-3238 92431444481 acquire: 0xffffffff81a4b398 dcache_lock
> perf-3238 92431446061 acquired: 0xffffffff81a4b398 dcache_lock
> perf-3238 92431448157 acquire: 0xffffffff81a4b398 dcache_lock
> perf-3238 92431449670 acquired: 0xffffffff81a4b398 dcache_lock
> perf-3238 92432371136 acquire: 0xffffffff81a4b398 dcache_lock
> perf-3238 92432372712 acquired: 0xffffffff81a4b398 dcache_lock
> perf-3238 92432374718 acquire: 0xffffffff81a4b398 dcache_lock
> perf-3238 92432376173 acquired: 0xffffffff81a4b398 dcache_lock
> perf-3238 92433315563 acquire: 0xffffffff81a4b398 dcache_lock
> perf-3238 92433317173 acquired: 0xffffffff81a4b398 dcache_lock
>
> There are too many acquire and acquired without corresponding release
> (or contended).
> If dcache_lock is rwlock and these acquires mean read locks, this is not
> so strange.
> But, for me, this is a pattern of dead lock.
> Of course perf lock finished its work, so there is no actual dead lock.
>
> If you know something about this behaviour of lock, could you tell me?
Well dcache_lock is a regular spinlock and there is only one of them, my
guess is that your timeline got messed up somehow.
Also, there doesn't appear to be a proper balance between acquires and
releases.
prev parent reply other threads:[~2010-04-10 14:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-10 10:44 Question about lock sequence Hitoshi Mitake
2010-04-10 13:07 ` Frederic Weisbecker
2010-04-10 15:12 ` Hitoshi Mitake
2010-04-16 8:44 ` [PATCH] perf lock: Fix state machine to recognize " Hitoshi Mitake
2010-04-21 1:26 ` Frederic Weisbecker
2010-04-21 8:55 ` Peter Zijlstra
2010-04-21 12:29 ` Hitoshi Mitake
2010-04-21 16:10 ` Frederic Weisbecker
2010-04-21 9:12 ` Hitoshi Mitake
2010-04-21 16:14 ` Frederic Weisbecker
2010-04-21 12:23 ` [PATCH v2] " Hitoshi Mitake
2010-04-22 22:54 ` Frederic Weisbecker
2010-04-27 12:55 ` [tip:perf/core] " tip-bot for Hitoshi Mitake
2010-04-10 14:01 ` Peter Zijlstra [this message]
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=1270908111.4222.4.camel@twins \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.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 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.