perf lock: track only specified threads
in [Kernel]
|
Prev: [PATCH -next] staging: fix cxt1e1 semaphore build breakage
Next: [GIT PULL for 2.6.34] V4L/DVB fixes
From: Frederic Weisbecker on 6 May 2010 21:00 On Thu, May 06, 2010 at 06:32:56PM +0900, Hitoshi Mitake wrote: > I implemented the feature of tracking only specified threads to perf lock. > With -t option, users can specify which threads should be tracked. > > Example of usage: > | % sudo ./perf lock info -t # info -t is convenient with this feature > | Thread ID: comm > | 0: swapper > | 1: init > | 12: migration/3 > | 13: ksoftirqd/3 > | 27: events/0 > | 28: events/1 > | 29: events/2 > | 30: events/3 > | 31: events/4 > | 857: kondemand/0 > | 858: kondemand/1 > | 859: kondemand/2 > | ... > | % sudo ./perf lock -t 27,28,29,30,31 report # track only these threads > | Name acquired contended total wait (ns) max wait (ns) min wait (ns) I'm not sure we want such per thread granularity filtering. I'm not sure it will be very useful. But per process yeah. And actually we should do that on tracing time rather than on post-processing. This will lower the tracing overhead a lot. Ideally I think we need: ./perf lock record ls -R / This would trace locks taken by this instance of ls only, ie: drop the -a if we pass a command line. What do you think? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Hitoshi Mitake on 8 May 2010 04:10
On 05/07/10 09:49, Frederic Weisbecker wrote: > On Thu, May 06, 2010 at 06:32:56PM +0900, Hitoshi Mitake wrote: >> I implemented the feature of tracking only specified threads to perf lock. >> With -t option, users can specify which threads should be tracked. >> >> Example of usage: >> | % sudo ./perf lock info -t # info -t is convenient with this feature >> | Thread ID: comm >> | 0: swapper >> | 1: init >> | 12: migration/3 >> | 13: ksoftirqd/3 >> | 27: events/0 >> | 28: events/1 >> | 29: events/2 >> | 30: events/3 >> | 31: events/4 >> | 857: kondemand/0 >> | 858: kondemand/1 >> | 859: kondemand/2 >> | ... >> | % sudo ./perf lock -t 27,28,29,30,31 report # track only these threads >> | Name acquired contended total wait (ns) max wait (ns) min wait (ns) > > > > I'm not sure we want such per thread granularity filtering. I'm not > sure it will be very useful. But per process yeah. > > And actually we should do that on tracing time rather than on post-processing. > This will lower the tracing overhead a lot. > > Ideally I think we need: > ./perf lock record ls -R / > > This would trace locks taken by this instance of ls only, ie: drop the -a > if we pass a command line. > > What do you think? > > Ah, I completely agree with your opinion :) Even if user wants to append "-a", ./perf lock record -a ls -R / is enough. "-a" should not in default set of arguments. I'll send the patch to drop "-a" later. Thanks, Hitoshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |