Re: [PATCH 0/2] (Was: Q: tracing: can we change trace_signal_generate() signature?)

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 2011-11-22 at 21:52 +0100, Oleg Nesterov wrote:
> O
> > Is "result" used for anything but tracepoints? When tracing is disabled,
> > the tracepoints should be just nops (when jump_label is enabled). Thus
> > tracing is very light. But if we are constantly calculating "result",
> > this is unused by those that don't use the tracing infrastructure, which
> > is 99.99% of all users. This is what I meant.
> 
> Ah I see. I thought you dislike OVERFLOW_FAIL/LOSE_INFO namely.
> 
> Of course, you are right. OTOH, this patch shaves 1058 bytes from
> .text. And without CONFIG_TRACE* gcc doesn't generate the extra code.

I was just noting that when tracing is disabled (CONFIG_TRACE* is set,
like it is on distros, but tracing is not happening), that we have extra
code. We usually strive to have tracing configured into the kernel, but
produces no (actually as little as possible) overhead when not actively
tracing.

That said, you know this code much more than I do. If this isn't a fast
path, and spinning a few more CPU cycles and perhaps dirtying a few
cache lines floats your boat. I'm OK with this change.

> 
> 
> 
> Oh. I simply do not know what can I do. Obviously, I'd like to avoid
> the new tracepoints in __send_signal(), imho this would be ugly. But
> the users want more info.
> 
> OK. let me send the patch at least for review. May be someone will
> nack it authoritatively, in this case I can relax and forward the
> nack back to bugzilla ;)

Again, if you don't think adding very slight overhead to this path is an
issue. Go ahead and add it.

> 
> However, at least 2/2 looks very reasonable to me. In fact it looks
> almost like the bug-fix.

2/2 looks to have the extra overhead to. Is the bug fix just with the
trace point.

Again, if you don't mind the overhead, then here:

Acked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve