linux-kernel - Re: [PATCH] perf lock: track only specified threads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 7 May 2010 02:49:47 +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: track only specified threads

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/