public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Question about lock sequence
@ 2010-04-10 10:44 Hitoshi Mitake
  2010-04-10 13:07 ` Frederic Weisbecker
  2010-04-10 14:01 ` Question about " Peter Zijlstra
  0 siblings, 2 replies; 14+ messages in thread
From: Hitoshi Mitake @ 2010-04-10 10:44 UTC (permalink / raw)
  To: LKML, Ingo Molnar, Peter Zijlstra, Frederic Weisbecker
  Cc: Paul Mackerras, Arnaldo Carvalho de Melo


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?

Thanks,
	Hitoshi


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2010-04-27 12:56 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 ` Question about " Peter Zijlstra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox