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

Message-ID: <4BE0FB68.7080403@kernel.org>
Date:	Wed, 05 May 2010 07:00:24 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	mingo@...e.hu, efault@....de, avi@...hat.com, paulus@...ba.org,
	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/04/2010 07:29 PM, Peter Zijlstra wrote:
>> * 0001-0007: Unify the three tracers (tracepoints, perf_events and
>>   preempt/sched notifiers) in scheduler.
> 
> Right, so I really don't like the SCHED_EVENT() thing much, esp the 3
> different function postfixes.

Yeap, it's not the prettiest thing.  I thought about renaming all of
them so that they share the same postfix but then again I need a way
to tell the script which to enable which is the easiest with
specifying postfixes as macro argument.  Any better ideas?

>> * 0008-0012: Move perf hooks in sched on top of tracepoints if TPs are
>>              enabled.
> 
> This seems to add a terrible amount of overhead for no particular
> reason.

Hmm... What overhead?

What matters more here is avoiding the overhead when perf or whatever
tracing mechanism is disabled.  When both perf and TPs are compiled in
but not enabled, moving perf hooks on top of TPs means that the sched
core code doesn't have to call into extra functions for perf and TPs
can be nooped.  ie. less overhead.  Also, even when perf is enabled,
there isn't any inherent extra runtime overhead other than during
enabling/disabling which again is a much colder path.

The only place where noticeable overhead is added is the extra pair of
irq enable/disable that I added for sched_out hook.  After glancing
through what perf does during context switch, I thought that overhead
wouldn't be anything noticeable but if it is, they can definitely be
separated.  The only purpose of that change was colocating sched
notifiers and perf hooks.

Also, if a few more perf hooks are converted to use the same
mechanism, it would be possible to put perf properly on top of TPs
other than init/exit code paths which will be cleaner for the rest of
the kernel and there won't be any extra runtime overhead.

The code will be much cleaner if perf depends on TPs.  With perf hooks
completely removed, there won't be much point in SCHED_EVENT and the
messy ifdefs in perf can also go away.  Would this be a possibility?

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/