public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	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, 2 Oct 2007 08:42:39 -0700	[thread overview]
Message-ID: <20071002084239.7371820c.randy.dunlap@oracle.com> (raw)
In-Reply-To: <1191332161.13204.70.camel@twins>

On Tue, 02 Oct 2007 15:36:01 +0200 Peter Zijlstra wrote:

> 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

Thanks.  Just some typos noted below.


> 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

                                      (non-0)

> +           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

       -bounces

> + acquisitions		- number of times we took the lock
> + hold time min		- shortest (non 0) time we ever held the lock

                                           (non-0)

> +           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 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
...
> +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

        excerpt

> +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.
...

---
~Randy

  reply	other threads:[~2007-10-02 15:43 UTC|newest]

Thread overview: 46+ 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  8:27     ` Chakri n
2007-09-28  8:40       ` Peter Zijlstra
2007-09-28  9:01         ` Chakri n
2007-09-28  9:12           ` Peter Zijlstra
2007-09-28  9:20             ` Chakri n
2007-09-28  9:23               ` Peter Zijlstra
2007-09-28 10:36                 ` Chakri n
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-29  1:27       ` Daniel Phillips
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:48       ` Peter Zijlstra
2007-09-28 19:16         ` Andrew Morton
2007-10-02 13:36           ` Peter Zijlstra
2007-10-02 15:42             ` Randy Dunlap [this message]
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?) Trond Myklebust
2007-09-28 19:26         ` Andrew Morton
2007-09-28 19:52           ` Trond Myklebust
2007-09-28 20:10             ` Andrew Morton
2007-09-28 20:32               ` Trond Myklebust
2007-09-28 20:43                 ` Andrew Morton
2007-09-28 21:36                   ` Chakri n
2007-09-28 23:33                     ` Chakri n
2007-09-28 20:24             ` Daniel Phillips
2007-09-29  1:51         ` KDB? Daniel Phillips
2007-09-29  0:46   ` A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?) Daniel Phillips
     [not found] ` <20070929110454.GA29861@mail.ustc.edu.cn>
2007-09-29 11:04   ` Fengguang Wu
2007-09-29 11:48     ` Peter Zijlstra
     [not found]       ` <20070929122842.GA5454@mail.ustc.edu.cn>
2007-09-29 12:28         ` Fengguang Wu
2007-09-29 14:43           ` Peter Zijlstra
2007-10-01 15:57     ` Chuck Ebbert
     [not found]       ` <20071002020040.GA5275@mail.ustc.edu.cn>
2007-10-02  2:00         ` [PATCH] writeback: avoid possible balance_dirty_pages() lockup on a light-load bdi Fengguang Wu
2007-10-02  2:14           ` Andrew Morton
     [not found]             ` <20071002121327.GA5718@mail.ustc.edu.cn>
2007-10-02 12:13               ` Fengguang Wu
     [not found]               ` <20071002132702.GA10967@mail.ustc.edu.cn>
2007-10-02 13:27                 ` Fengguang Wu
2007-10-02 18:35                   ` Chuck Ebbert
2007-10-03 12:46         ` richard kennedy
     [not found]           ` <20071004015053.GA5789@mail.ustc.edu.cn>
2007-10-04  1:50             ` Fengguang Wu

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=20071002084239.7371820c.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox