All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Peschke <mp3@de.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, jbaron@redhat.com,
	rostedt@goodmis.org, linux-s390@vger.kernel.org
Subject: Re: [RFC] [Patch 4/4] lock contention tracking slimmed down
Date: Thu, 07 Jun 2007 08:59:15 +0200	[thread overview]
Message-ID: <4667ACC3.60009@de.ibm.com> (raw)
In-Reply-To: <1181198376.7348.202.camel@twins>

Peter Zijlstra wrote:
> On Thu, 2007-06-07 at 02:17 +0200, Martin Peschke wrote:
>> Ingo Molnar wrote:
>>> * Martin Peschke <mp3@de.ibm.com> wrote:
>>>
>>>> The output has changed from a terribly wide table to an enormously 
>>>> long list (just the generic way the statistics code prints data). 
>>> Sigh, why dont you _ask_ before doing such stuff?
>> A nice diffstat is always worth a try, isn't it?
>> And I see other reasons for code sharing.
>> Ah, and doing it has been actually quite simple once I had figured out
>> what the original code does. :-)
>>
>>> It is a terribly wide table because that makes it easily greppable
>> If one looks for contentions of "xtime_lock" within my enormously long list,
>> they could issue:
>>
>>     grep -e "xtime_lock contentions" data
>>
>> and get
>>
>>     xtime_lock contentions 0x17bd2 3327 account_ticks+0x96/0x184
>>     xtime_lock contentions other 0
>>
>> for example.
>>
>> So how is this worse?
> 
> How will you find the 5 most contended locks with 1 grep?
> 
> It used to be:
>   grep ":" /proc/lock_stat | head -n 5

grep "contention" data |sort -k 4 -n |tail -n 5

&rq->rq_lock_key contentions 0x34c04 613 task_rq_lock+0x64/0xb0
&zone->lock contentions 0x8322e 770 __free_pages_ok+0x1b2/0x534
&zone->lock contentions 0x82828 1017 free_pages_bulk+0x40/0x42c
xtime_lock contentions 0x17bd2 3327 account_ticks+0x96/0x184
&inode->i_mutex contentions 0x3273ee 8807 mutex_lock+0x3e/0x4c

Admittedly this gives you the top five contention points, as my prototype
tracks this without accounting the total number of contentions for a
given lock in another counter.

If the above command line isn't good enough, we could easily put a total
contentions counter for each lock back in (see lock_stat_info).

> 
> lock stat is more about finding who is bad than examining a particular
> lock (of course in the process of fixing that lock, that does become
> interesting).

Sure. I guess that applies to most other statistics.

  reply	other threads:[~2007-06-07  6:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 21:34 [RFC] [Patch 4/4] lock contention tracking slimmed down Martin Peschke
2007-06-06 23:06 ` Ingo Molnar
2007-06-07  0:17   ` Martin Peschke
2007-06-07  4:40     ` Bill Huey
2007-06-07  7:03       ` Martin Peschke
2007-06-07  7:30         ` Ingo Molnar
2007-06-07  8:56           ` Bill Huey
2007-06-11 11:26             ` Martin Peschke
2007-06-08 16:27           ` Martin Peschke
2007-06-07  6:39     ` Peter Zijlstra
2007-06-07  6:59       ` Martin Peschke [this message]
2007-06-07  7:27         ` Ingo Molnar
2007-06-08 16:07           ` Martin Peschke
2007-06-06 23:10 ` Ingo Molnar
2007-06-07  0:21   ` Martin Peschke
2007-06-07  7:44 ` Peter Zijlstra
2007-06-08 17:00   ` Martin Peschke
     [not found]     ` <1181322460.5728.2.camel@lappy>
     [not found]       ` <46698F7F.4090407@de.ibm.com>
2007-06-08 17:27         ` Peter Zijlstra
2007-06-08 17:37           ` Martin Peschke
2007-06-08 17:50             ` Peter Zijlstra
2007-06-11 10:31               ` Martin Peschke
2007-06-07  7:51 ` Peter Zijlstra
2007-06-08 17:13   ` Martin Peschke
2007-06-07  8:17 ` Peter Zijlstra
2007-06-07 10:21   ` Ingo Molnar
2007-06-11 12:20   ` Martin Peschke

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=4667ACC3.60009@de.ibm.com \
    --to=mp3@de.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=jbaron@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.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.