All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Zach Brown <zach.brown@oracle.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?)
Date: Tue, 02 Oct 2007 15:36:01 +0200	[thread overview]
Message-ID: <1191332161.13204.70.camel@twins> (raw)
In-Reply-To: <20070928121642.56a380ce.akpm@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 7430 bytes --]

On Fri, 2007-09-28 at 12:16 -0700, Andrew Morton wrote:

> (Searches for the lockstat documentation)
> 
> Did we forget to do that?

yeah,...

/me quickly whips up something

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 Documentation/lockstat.txt |  119 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 119 insertions(+)

Index: linux-2.6/Documentation/lockstat.txt
===================================================================
--- /dev/null
+++ linux-2.6/Documentation/lockstat.txt
@@ -0,0 +1,119 @@
+
+LOCK STATISTICS
+
+- WHAT
+
+As the name suggests, it provides statistics on locks.
+
+- WHY
+
+Because things like lock contention can severely impact performance.
+
+- HOW
+
+Lockdep already has hooks in the lock functions and maps lock instances to
+lock classes. We build on that. The graph below shows the relation between
+the lock functions and the various hooks therein.
+
+        __acquire
+            |
+           lock _____
+            |        \
+            |    __contended
+            |         |
+            |       <wait>
+            | _______/
+            |/
+            |
+       __acquired
+            |
+            .
+          <hold>
+            .
+            |
+       __release
+            |
+         unlock
+
+lock, unlock	- the regular lock functions
+__*		- the hooks
+<> 		- states
+
+With these hooks we provide the following statistics:
+
+ con-bounces		- number of lock contention that involved x-cpu data
+ contentions            - number of lock acquisitions that had to wait
+ wait time min          - shortest (non 0) time we ever had to wait for a lock
+           max          - longest time we ever had to wait for a lock
+           total        - total time we spend waiting on this lock
+ acq-bounes             - number of lock acquisitions that involved x-cpu data
+ acquisitions		- number of times we took the lock
+ hold time min		- shortest (non 0) time we ever held the lock
+           max		- longest time we ever held the lock
+           total	- total time this lock was held
+
+From these number various other statistics can be derived, such as:
+
+ hold time average = hold time total / acquisitions
+
+These numbers are gathered per lock class, per read/write state (when
+applicable).
+
+It also tracks (4) contention points per class. A contention point is a call
+site that had to wait on lock acquisition.
+
+ - USAGE
+
+Look at the current lock statistics:
+
+(line numbers not part of actual output, done for clarity in the explanation below)
+
+# less /proc/lock_stat
+
+01 lock_stat version 0.2
+02 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+03                               class name    con-bounces    contentions   waittime-min   waittime-max waittime-total    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total
+04 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+05
+06               &inode->i_data.tree_lock-W:            15          21657           0.18     1093295.30 11547131054.85             58          10415           0.16          87.51        6387.60
+07               &inode->i_data.tree_lock-R:             0              0           0.00           0.00           0.00          23302         231198           0.25           8.45       98023.38
+08               --------------------------
+09                 &inode->i_data.tree_lock              0          [<ffffffff8027c08f>] add_to_page_cache+0x5f/0x190
+10
+11 ...............................................................................................................................................................................................
+12
+13                              dcache_lock:          1037           1161           0.38          45.32         774.51           6611         243371           0.15         306.48       77387.24
+14                              -----------
+15                              dcache_lock            180          [<ffffffff802c0d7e>] sys_getcwd+0x11e/0x230
+16                              dcache_lock            165          [<ffffffff802c002a>] d_alloc+0x15a/0x210
+17                              dcache_lock             33          [<ffffffff8035818d>] _atomic_dec_and_lock+0x4d/0x70
+18                              dcache_lock              1          [<ffffffff802beef8>] shrink_dcache_parent+0x18/0x130
+
+This except shows the first two lock class statistics. Line 01 shows the output
+version - each time the format changes this will be updated. Line 02-04 show
+the header with column descriptions. Lines 05-10 and 13-18 show the actual
+statistics. These statistics come in two parts; the actual stats separated by a
+short separator (line 08, 14) from the contention points.
+
+The first lock (05-10) is a read/write lock, and shows two lines above the
+short separator. The contention points don't match the column descriptors,
+they have two: contentions and [<IP>] symbol.
+
+
+View the top contending locks:
+
+# grep : /proc/lock_stat | head
+              &inode->i_data.tree_lock-W:            15          21657           0.18     1093295.30 11547131054.85             58          10415           0.16          87.51        6387.60
+              &inode->i_data.tree_lock-R:             0              0           0.00           0.00           0.00          23302         231198           0.25           8.45       98023.38
+                             dcache_lock:          1037           1161           0.38          45.32         774.51           6611         243371           0.15         306.48       77387.24
+                         &inode->i_mutex:           161            286 18446744073709       62882.54     1244614.55           3653          20598 18446744073709       62318.60     1693822.74
+                         &zone->lru_lock:            94             94           0.53           7.33          92.10           4366          32690           0.29          59.81       16350.06
+              &inode->i_data.i_mmap_lock:            79             79           0.40           3.77          53.03          11779          87755           0.28         116.93       29898.44
+                        &q->__queue_lock:            48             50           0.52          31.62          86.31            774          13131           0.17         113.08       12277.52
+                        &rq->rq_lock_key:            43             47           0.74          68.50         170.63           3706          33929           0.22         107.99       17460.62
+                      &rq->rq_lock_key#2:            39             46           0.75           6.68          49.03           2979          32292           0.17         125.17       17137.63
+                         tasklist_lock-W:            15             15           1.45          10.87          32.70           1201           7390           0.58          62.55       13648.47
+
+Clear the statistics:
+
+# echo 0 > /proc/lock_stat


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-10-02 13:36 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-28  6:32 A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?) Chakri n
2007-09-28  6:50 ` Andrew Morton
2007-09-28  6:59   ` Peter Zijlstra
2007-09-28  6:59   ` Peter Zijlstra
2007-09-28  8:27     ` Chakri n
2007-09-28  8:27     ` Chakri n
2007-09-28  8:27       ` Chakri n
2007-09-28  8:40       ` Peter Zijlstra
2007-09-28  9:01         ` Chakri n
2007-09-28  9:01         ` Chakri n
2007-09-28  9:01           ` Chakri n
2007-09-28  9:12           ` Peter Zijlstra
2007-09-28  9:12           ` Peter Zijlstra
2007-09-28  9:20             ` Chakri n
2007-09-28  9:20             ` Chakri n
2007-09-28  9:20               ` Chakri n
2007-09-28  9:23               ` Peter Zijlstra
2007-09-28  9:23               ` Peter Zijlstra
2007-09-28  9:23                 ` Peter Zijlstra
2007-09-28 10:36                 ` Chakri n
2007-09-28 10:36                 ` Chakri n
2007-09-28 10:36                   ` Chakri n
2007-09-28  8:40       ` Peter Zijlstra
2007-09-28 13:28   ` Jonathan Corbet
2007-09-28 13:28   ` Jonathan Corbet
2007-09-28 13:28     ` Jonathan Corbet
2007-09-28 13:35     ` Peter Zijlstra
2007-09-28 16:45       ` [linux-pm] " Alan Stern
2007-09-28 16:45         ` Alan Stern
2007-09-28 16:45       ` Alan Stern
2007-09-29  1:27       ` Daniel Phillips
2007-09-29  1:27         ` Daniel Phillips
2007-09-29  1:27       ` Daniel Phillips
2007-09-28 13:35     ` Peter Zijlstra
2007-09-28 18:04     ` Andrew Morton
2007-09-28 18:04       ` Andrew Morton
2007-09-28 18:04       ` Andrew Morton
2007-09-28 17:00   ` Trond Myklebust
2007-09-28 18:49     ` Andrew Morton
2007-09-28 18:49       ` Andrew Morton
2007-09-28 18:48       ` Peter Zijlstra
2007-09-28 18:48       ` Peter Zijlstra
2007-09-28 19:16         ` Andrew Morton
2007-09-28 19:16           ` Andrew Morton
2007-10-02 13:36           ` Peter Zijlstra [this message]
2007-10-02 15:42             ` Randy Dunlap
2007-10-03  9:28               ` [PATCH] lockstat: documentation Peter Zijlstra
2007-10-03  9:35                 ` Ingo Molnar
2007-09-28 19:16         ` A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?) Andrew Morton
2007-09-28 19:16       ` Trond Myklebust
2007-09-28 19:26         ` Andrew Morton
2007-09-28 19:26           ` Andrew Morton
2007-09-28 19:52           ` Trond Myklebust
2007-09-28 19:52           ` Trond Myklebust
2007-09-28 19:52             ` Trond Myklebust
2007-09-28 20:10             ` Andrew Morton
2007-09-28 20:10               ` Andrew Morton
2007-09-28 20:32               ` Trond Myklebust
2007-09-28 20:32                 ` Trond Myklebust
2007-09-28 20:43                 ` Andrew Morton
2007-09-28 20:43                   ` Andrew Morton
2007-09-28 21:36                   ` Chakri n
2007-09-28 21:36                   ` Chakri n
2007-09-28 23:33                     ` Chakri n
2007-09-28 23:33                     ` Chakri n
2007-09-28 23:33                       ` Chakri n
2007-09-28 20:32               ` Trond Myklebust
2007-09-28 20:10             ` Andrew Morton
2007-09-28 20:24             ` Daniel Phillips
2007-09-28 20:24             ` Daniel Phillips
2007-09-28 19:26         ` Andrew Morton
2007-09-29  1:51         ` KDB? Daniel Phillips
2007-09-29  1:51           ` KDB? Daniel Phillips
2007-09-29  1:51         ` KDB? Daniel Phillips
2007-09-28 19:16       ` A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?) Trond Myklebust
2007-09-28 18:49     ` Andrew Morton
2007-09-28 17:00   ` Trond Myklebust
2007-09-29  0:46   ` Daniel Phillips
2007-09-29  0:46   ` Daniel Phillips
2007-09-29  0:46     ` Daniel Phillips
2007-09-28  6:50 ` Andrew Morton
2007-09-29 11:04 ` Fengguang Wu
2007-09-29 11:04   ` Fengguang Wu
2007-09-29 11:04   ` Fengguang Wu
2007-09-29 11:48     ` Peter Zijlstra
2007-09-29 11:48     ` Peter Zijlstra
2007-09-29 12:28       ` Fengguang Wu
2007-09-29 12:28         ` Fengguang Wu
2007-09-29 12:28         ` Fengguang Wu
2007-09-29 14:43           ` Peter Zijlstra
2007-09-29 14:43           ` Peter Zijlstra
2007-10-01 15:57     ` Chuck Ebbert
2007-10-02  2:00       ` [PATCH] writeback: avoid possible balance_dirty_pages() lockup on a light-load bdi Fengguang Wu
2007-10-02  2:00         ` Fengguang Wu
2007-10-02  2:00         ` Fengguang Wu
2007-10-02  2:14           ` Andrew Morton
2007-10-02  2:14             ` Andrew Morton
2007-10-02 12:13             ` Fengguang Wu
2007-10-02 12:13               ` Fengguang Wu
2007-10-02 12:13               ` Fengguang Wu
2007-10-02 13:27               ` Fengguang Wu
2007-10-02 13:27                 ` Fengguang Wu
2007-10-02 18:35                   ` Chuck Ebbert
2007-10-02 18:35                     ` Chuck Ebbert
2007-10-02 13:27                 ` Fengguang Wu
2007-10-03 12:46         ` richard kennedy
2007-10-03 12:46         ` richard kennedy
2007-10-04  1:50           ` Fengguang Wu
2007-10-04  1:50             ` Fengguang Wu
2007-10-04  1:50             ` Fengguang Wu
2007-10-01 15:57     ` A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?) Chuck Ebbert
  -- strict thread matches above, loose matches on Subject: below --
2007-09-28  6:32 Chakri n

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=1191332161.13204.70.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=zach.brown@oracle.com \
    /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.