Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751835Ab0DJKoN (ORCPT ); Sat, 10 Apr 2010 06:44:13 -0400 Received: from ns.dcl.info.waseda.ac.jp ([133.9.216.194]:60590 "EHLO ns.dcl.info.waseda.ac.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750918Ab0DJKoJ (ORCPT ); Sat, 10 Apr 2010 06:44:09 -0400 Message-ID: <4BC05677.7070406@dcl.info.waseda.ac.jp> Date: Sat, 10 Apr 2010 19:44:07 +0900 From: Hitoshi Mitake User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091211 Shredder/3.0 MIME-Version: 1.0 To: LKML , Ingo Molnar , Peter Zijlstra , Frederic Weisbecker CC: Paul Mackerras , Arnaldo Carvalho de Melo Subject: Question about lock sequence Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2040 Lines: 49 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: # -