All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
	linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [PATCH 0/5] lockdep: Add information of file and line to lockdep_map
Date: Wed, 13 Jan 2010 11:09:26 +0100	[thread overview]
Message-ID: <20100113100926.GB11386@elte.hu> (raw)
In-Reply-To: <1263376323.4244.204.camel@laptop>


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2010-01-07 at 19:39 +0900, Hitoshi Mitake wrote:
> > There are a lot of lock instances with same names (e.g. port_lock).
> > This patch series add __FILE__ and __LINE__ to lockdep_map,
> > and these will be used for trace lock events.
> > 
> > Example use from perf lock map:
> > 
> > | 0xffffea0004c992b8: __pte_lockptr(page) (src: include/linux/mm.h, line: 952)
> > | 0xffffea0004b112b8: __pte_lockptr(page) (src: include/linux/mm.h, line: 952)
> > | 0xffffea0004a3f2b8: __pte_lockptr(page) (src: include/linux/mm.h, line: 952)
> > | 0xffffea0004cd5228: __pte_lockptr(page) (src: include/linux/mm.h, line: 952)
> > | 0xffff8800b91e2b28: &sb->s_type->i_lock_key (src: fs/inode.c, line: 166)
> > | 0xffff8800bb9d7ae0: key (src: kernel/wait.c, line: 16)
> > | 0xffff8800aa07dae0: &dentry->d_lock (src: fs/dcache.c, line: 944)
> > | 0xffff8800b07fbae0: &dentry->d_lock (src: fs/dcache.c, line: 944)
> > | 0xffff8800b07f3ae0: &dentry->d_lock (src: fs/dcache.c, line: 944)
> > | 0xffff8800bf15fae0: &sighand->siglock (src: kernel/fork.c, line: 1490)
> > | 0xffff8800b90f7ae0: &dentry->d_lock (src: fs/dcache.c, line: 944)
> > | ...
> > 
> > (This output of perf lock map is produced by my local version,
> >  I'll send this later.)
> > 
> > And sadly, as Peter Zijlstra predicted, this produces certain overhead.
> > 
> > Before appling this series:
> > | % sudo ./perf lock rec perf bench sched messaging
> > | # Running sched/messaging benchmark...
> > | # 20 sender and receiver processes per group
> > | # 10 groups == 400 processes run
> > |
> > |      Total time: 3.834 [sec]
> > After:
> >  sudo ./perf lock rec perf bench sched messaging
> > | # Running sched/messaging benchmark...
> > | # 20 sender and receiver processes per group
> > | # 10 groups == 400 processes run
> > |
> > |      Total time: 5.415 [sec]
> > | [ perf record: Woken up 0 times to write data ]
> > | [ perf record: Captured and wrote 53.512 MB perf.data (~2337993 samples) ]
> > 
> > But raw exec of perf bench sched messaging is this:
> > | % perf bench sched messaging
> > | # Running sched/messaging benchmark...
> > | # 20 sender and receiver processes per group
> > | # 10 groups == 400 processes run
> > |
> > |      Total time: 0.498 [sec]
> > 
> > Tracing lock events already produces amount of overhead.
> > I think the overhead produced by this series is not a fatal problem,
> > radically optimization is required... 
> 
> Right, these patches look OK, for the tracing overhead, you could possibly 
> hash the file:line into a u64 and reduce the tracepoint size, that should 
> improve the situation I tihnk, because I seem to remember the only thing 
> that really matters for speed is the size of things.

ok, great. I looked into merging these bits into perf/lock and perf/lock into 
tip:master - but the recent upstream raw-spinlock changes interact with the 
new patches.

I also merged latest perf into perf/lock and there's some new build failures:

builtin-lock.c:14:27: error: util/data_map.h: No such file or directory
cc1: warnings being treated as errors
builtin-lock.c: In function 'process_sample_event':
builtin-lock.c:279: error: implicit declaration of function 'threads__findnew'
builtin-lock.c:279: error: nested extern declaration of 'threads__findnew'
builtin-lock.c:279: error: assignment makes pointer from integer without a cast
builtin-lock.c: At top level:
builtin-lock.c:357: error: variable 'file_handler' has initializer but incomplete type
builtin-lock.c:358: error: unknown field 'process_sample_event' specified in initializer
builtin-lock.c:358: error: excess elements in struct initializer
builtin-lock.c:358: error: (near initialization for 'file_handler')
builtin-lock.c:359: error: unknown field 'sample_type_check' specified in initializer
builtin-lock.c:359: error: excess elements in struct initializer
builtin-lock.c:359: error: (near initialization for 'file_handler')
builtin-lock.c: In function 'read_events':
builtin-lock.c:364: error: implicit declaration of function 'register_idle_thread'
builtin-lock.c:364: error: nested extern declaration of 'register_idle_thread'
builtin-lock.c:365: error: implicit declaration of function 'register_perf_file_handler'
builtin-lock.c:365: error: nested extern declaration of 'register_perf_file_handler'
builtin-lock.c:367: error: implicit declaration of function 'mmap_dispatch_perf_file'
builtin-lock.c:367: error: nested extern declaration of 'mmap_dispatch_perf_file'
builtin-lock.c:368: error: 'event__cwdlen' undeclared (first use in this function)
builtin-lock.c:368: error: (Each undeclared identifier is reported only once
builtin-lock.c:368: error: for each function it appears in.)
builtin-lock.c:368: error: 'event__cwd' undeclared (first use in this function)
builtin-lock.c: In function 'cmd_lock':
builtin-lock.c:429: error: too many arguments to function 'symbol__init'
make: *** [builtin-lock.o] Error 1
make: *** Waiting for unfinished jobs....

once those are resolved and we have the merged in patches we can graduate this 
topic into tip:master.

Thanks,

	Ingo

  reply	other threads:[~2010-01-13 10:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-16  3:28 [PATCH 1/2] perf: Add util/include/linuxhash.h to include hash.h of kernel Hitoshi Mitake
2009-12-16  3:28 ` [PATCH 2/2] perf lock: Fix output of tracing lock events Hitoshi Mitake
2009-12-16  8:19   ` [tip:perf/lock] " tip-bot for Hitoshi Mitake
2009-12-17  8:50   ` [PATCH 2/2] " Ingo Molnar
2009-12-17  9:24   ` Peter Zijlstra
2009-12-17 10:09     ` Ingo Molnar
2009-12-17 10:26       ` Peter Zijlstra
2009-12-17 10:51         ` Ingo Molnar
2009-12-26 13:43     ` Hitoshi Mitake
2009-12-28 10:01       ` Peter Zijlstra
2009-12-31 13:24         ` Hitoshi Mitake
2010-01-07 10:38           ` Hitoshi Mitake
2010-01-07 10:39             ` [PATCH 0/5] lockdep: Add information of file and line to lockdep_map Hitoshi Mitake
2010-01-13  9:52               ` Peter Zijlstra
2010-01-13 10:09                 ` Ingo Molnar [this message]
2010-01-16 13:01                 ` Hitoshi Mitake
2010-01-18  7:20                   ` Peter Zijlstra
2010-01-26  5:56                     ` [PATCH] Add type of locks to lock trace events Hitoshi Mitake
2010-01-28 10:21                       ` Peter Zijlstra
2010-01-29 17:29                         ` Frederic Weisbecker
2010-01-29 17:41                           ` Peter Zijlstra
2010-01-29 22:12                             ` Frederic Weisbecker
2010-02-24  9:02                               ` [PATCH] Separate lock events with types Hitoshi Mitake
2010-03-26 23:33                                 ` Frederic Weisbecker
2010-04-05 10:37                                   ` Hitoshi Mitake
2010-04-06  8:26                                   ` Peter Zijlstra
2010-04-06  9:44                                     ` Frederic Weisbecker
2010-01-07 10:39             ` [PATCH 1/5] lockdep: Add file and line to initialize sequence of spin and rw lock Hitoshi Mitake
2010-01-07 10:39             ` [PATCH 2/5] lockdep: Add file and line to initialize sequence of rwsem Hitoshi Mitake
2010-01-07 10:39             ` [PATCH 3/5] " Hitoshi Mitake
2010-01-07 10:39             ` [PATCH 4/5] lockdep: Add file and line to initialize sequence of mutex Hitoshi Mitake
2010-01-07 10:39             ` [PATCH 5/5] lockdep: Fix the way to initialize class_mutex for information of file and line Hitoshi Mitake
2010-01-13 10:00               ` Ingo Molnar
2010-01-13 23:17                 ` Greg KH
2010-01-13 23:19                   ` Greg KH
2010-01-16 12:55                     ` Hitoshi Mitake
2009-12-16  8:18 ` [tip:perf/lock] perf: Add util/include/linuxhash.h to include hash.h of kernel tip-bot for Hitoshi Mitake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100113100926.GB11386@elte.hu \
    --to=mingo@elte.hu \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mitake@dcl.info.waseda.ac.jp \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.