linux-kernel - Re: [RFC PATCHSET] sched,perf: unify tracers in sched and move perf on top of TP

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] [day] [month] [year] [list]

Date:	Mon, 10 May 2010 07:48:54 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Paul Mackerras <paulus@...ba.org>
CC:	Peter Zijlstra <peterz@...radead.org>, mingo@...e.hu,
	efault@....de, avi@...hat.com, acme@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCHSET] sched,perf: unify tracers in sched and move perf
 on top of TP

Hello,

On 05/10/2010 07:20 AM, Paul Mackerras wrote:
> Don't forget where perf_events started out - as a way to count and
> record hardware events.  So perf_events is very useful even in a
> kernel that has no tracing infrastructure configured in at all. 

Alright, but I don't think it's very relevant to worry about
!CONFIG_TRACEPOINTS && CONFIG_PERF_EVENTS case as long as both can be
compiled out.  TPs are supposed to have very low to almost no runtime
overhead and building them into the kernel shouldn't cost all that
much either (I hear that it has been improved lately).  Sure, perf can
be used w/o TPs but I can't see what that configurability buys us.

Thanks.

-- 
tejun
--
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/