Messages in this thread | | | Subject | Re: [PATCH 0/2] (Was: Q: tracing: can we change trace_signal_generate() signature?) | From | Steven Rostedt <> | Date | Fri, 02 Dec 2011 12:53:05 -0500 |
| |
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
| |