[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100508161404.GB5444@nowhere>
Date: Sat, 8 May 2010 18:14:06 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Cc: linux-kernel@...r.kernel.org, h.mitake@...il.com,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Paul Mackerras <paulus@...ba.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Jens Axboe <jens.axboe@...cle.com>,
Jason Baron <jbaron@...hat.com>,
Xiao Guangrong <xiaoguangrong@...fujitsu.com>
Subject: Re: [PATCH] perf lock: Drop "-a" option from set of default
arguments to cmd_record()
On Sat, May 08, 2010 at 05:10:29PM +0900, Hitoshi Mitake wrote:
> This patch drops "-a" from record_args, which is passed to cmd_record().
>
> Even if user wants to record all lock events during process runs,
> perf lock record -a <program> <argument> ...
> is enough for this purpose.
>
> This can reduce size of perf.data.
>
> % sudo ./perf lock record whoami
> root
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.439 MB perf.data (~19170 samples) ]
> % sudo ./perf lock record -a whoami # with -a option
> root
> [ perf record: Woken up 0 times to write data ]
> [ perf record: Captured and wrote 48.962 MB perf.data (~2139197 samples) ]
>
> This patch was made on perf/test of random-tracing.git,
> could you queue this, Frederic?
>
> Cc: Ingo Molnar <mingo@...e.hu>
> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Cc: Paul Mackerras <paulus@...ba.org>
> Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
> Cc: Jens Axboe <jens.axboe@...cle.com>
> Cc: Jason Baron <jbaron@...hat.com>
> Cc: Xiao Guangrong <xiaoguangrong@...fujitsu.com>
> Signed-off-by: Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Thanks, will test it and if it's fine I'll queue.
I did a lot of tests these last days to understand what was going on
with perf lock, I mean the fact we have various bad locking scenario.
So far, the state machine looks rather good. In fact, the real problem
is that we don't have every events. We lose a _lot_ of them and that's
because the frequency of lock events is too high and perf record
can't keep up.
I think I'm going to unearth the injection code to reduce the size
of these events.
--
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