lkml.org 
[lkml]   [2010]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] perf lock: Drop "-a" option from set of default arguments to cmd_record()
On 05/09/10 01:14, Frederic Weisbecker wrote:
> 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@elte.hu>
>> Cc: Peter Zijlstra<a.p.zijlstra@chello.nl>
>> Cc: Paul Mackerras<paulus@samba.org>
>> Cc: Arnaldo Carvalho de Melo<acme@redhat.com>
>> Cc: Jens Axboe<jens.axboe@oracle.com>
>> Cc: Jason Baron<jbaron@redhat.com>
>> Cc: Xiao Guangrong<xiaoguangrong@cn.fujitsu.com>
>> Signed-off-by: Hitoshi Mitake<mitake@dcl.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.

Really, I didn't think about lack of events :(

>
> I think I'm going to unearth the injection code to reduce the size
> of these events.
>
>

Yeah, injection will be really helpful thing.

And I have a rough idea for reducing event frequency.

Many lock event sequences are like this form:
* acquire -> acquired -> release
* acquire -> contended -> acquired -> release
I think that making 3 or 4 events per each lock sequences
is waste of CPU time and memory space.

If threads store time of each events
and make only 1 event at time of release,
we will be able to reduce lots of time and space.

For example, ID of each lock instance is 8 byte in x86_64.
In this scheme 8 * 4 byte for ID will be only 8 byte.
I think this optimization has worth to consider because of
high frequency of lock events.

How do you think?


\
 
 \ /
  Last update: 2010-05-09 16:57    [W:0.127 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site