linux-kernel - Re: [PATCH 00/12] perf lock: New subcommand "perf lock", for analyzing lock statistics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100201175812.GC5241@nowhere>
Date:	Mon, 1 Feb 2010 18:58:14 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Hitoshi Mitake <mitake@....info.waseda.ac.jp>,
	linux-kernel@...r.kernel.org, Paul Mackerras <paulus@...ba.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Steven Rostedt <srostedt@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH 00/12] perf lock: New subcommand "perf lock", for
	analyzing  lock statistics

On Mon, Feb 01, 2010 at 10:22:39AM +0100, Ingo Molnar wrote:
> 
> * Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > On Sun, 2010-01-31 at 22:07 +0100, Frederic Weisbecker wrote:
> > > 
> > > - We are using the -M option from perf tools which multiplexes every
> > >   event buffers, which means every cpu commit their lock events in
> > >   the same buffer. Couple that with the two above reasons, it's supposed
> > >   to scale at worst.
> > 
> > Why are you doing that? That seems like asking for trouble.. 
> 
> But as i said i already tried with -M off and it didnt cure the slowdown.


Ah.. I've tested the lock events in an atom (two hardware threads) and there
is quite a slowdown too.

Anyway, the patches to remove the string copies from critical lock events
are soon to be ready now. I just suspect there are other problems somewhere
else that cause the slowdown.


> 
> that -M was just copied over from perf sched (where it makes sense).
> 
> 	Ingo



For now it is necessary, because we need the events to be ordered by time,
otherwise the state machine in perf lock would be broken.
We can certainly reorder the events in post-processing, but lock events
tend to grow the file _very_ quickly, so I fear this is going to require
lot of memory. I'll try to find a smart way to fix that.

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