Messages in this thread | | | Date | Sun, 09 May 2010 23:53:19 +0900 | From | Hitoshi Mitake <> | Subject | Re: [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?
| |