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]

Date:	Wed, 05 May 2010 11:32:35 +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/05/2010 11:06 AM, Peter Zijlstra wrote:
>> 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?
> 
> Add more NOP functions for the missing bits I guess, but that gets
> cumbersome too.

Hmm... yeah, we'll need NOP functions for every missing hook.  Might
as well just spell each one out.

>> Hmm... What overhead?
> 
> Well, the perf_{inc,dec}_nr_events() stuff, that's massively painful. If
> that is the price to pay for using tracepoints then I'd rather not.

Ah, okay, you mean the code complexity overhead.  Eh well, if you
wanna do it on-demand, there's certain amount you need to pay.  As
long as the runtime overhead on hotpath isn't increased, I don't think
it's too bad tho.

> Also, the whole magic dance to keep !CONFIG_TRACEPOINTS working doesn't
> make the code any saner.

Things would have been much prettier if PERF could simply depend on
TRACEPOINTS.  More on this later.

> Well, in the current code we get the call overhead, but all perf
> functions bail on !nr_events. We could invert that and have an inline
> function check nr_events and only then do the call.

The thing is that unifying hooks not only saves the extra check now
but also makes future optimizations much easier.  ie. Ingo was talking
about run time patching TPs so that disabled ones just become noops.
It's far better to have all the tracing stuff on single hooking
mechanism for optimization efforts like that.

> Right, recent Intel chips seem to do much better at IRQ disable than say
> P4 and IA64, and poking at the PMU MSRs is way more painful, not sure
> how it would balance out for PowerPC (or anything other) though.

As I wrote above, here, the problem is mostly cosmetic.  It's just
that kvm hook needs irq on while perf hook can save one irq flipping
if called with irq off.  If we call them separately, there's no
problem.  If we wanna colocate them, it makes sense to pull perf hook
out of irq disabled section.  This one doesn't really make that much
of a difference.

> Well, I already utterly hate that x86 can't build with !
> CONFIG_PERF_EVENTS, also requiring CONFIG_TRACEPOINTS is going the wrong
> way.
> 
> I've always explicitly avoided depending on tracepoints, and I'd very
> much like to keep it that way.

I was wondering the other way around - ie. the possibility to make
perf optional and maybe even as a module which depends on TPs, which
would be nicer than the current situation and make the code less
cluttered too.

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/