[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1181198376.7348.202.camel@twins>
Date: Thu, 07 Jun 2007 08:39:36 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Martin Peschke <mp3@...ibm.com>
Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
jbaron@...hat.com, rostedt@...dmis.org, linux-s390@...r.kernel.org
Subject: Re: [RFC] [Patch 4/4] lock contention tracking slimmed down
On Thu, 2007-06-07 at 02:17 +0200, Martin Peschke wrote:
> Ingo Molnar wrote:
> > * Martin Peschke <mp3@...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
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).
Nor was it _that_ wide, it easily fit into an xterm, even on my laptop.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists