tracing: signal tracepoints
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 1 replyIn review
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
| Patch | Seiji Aguchi | Steven Rostedt |
|---|---|---|
| Series | R-b R-b | A-b A-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH RESEND 0/2] tracing: signal tracepoints
Steven, sorry for delay...
Quoted 11 lines · Steven Rostedt
Quoted 9 lines · Oleg Nesterov
Quoted 6 lines
Is "result" used for anything but tracepoints? When tracing is disabled, the tracepoints should be just nops (when
jump_labelis 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.
Quoted 8 lines
Quoted 2 lines
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.
Yes, yes, I see. But I do not see any alternative. Of course, instead of adding "int result" we could add more trace_signal_generate's into the code, but imho this is too ugly. And in fact I am not sure this means less overhead with CONFIG_TRACE* even if this code is nop'ed.
Quoted 3 lines
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.
I simply do not know. I _think_ that the overhead is negligible, the extra calculating just adds a couple of "mov CONSTANT, REGISTER" insns.
Quoted 10 lines
Quoted 7 lines
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.
OK, thanks.
The next question is, how can I add it ;) May be Ingo or Andrew could take these patches? Original signal tracepoints were routed via tip-tree...
Add them both to TO:, lets see who is kinder.
Quoted 9 lines
Quoted 2 lines
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 <[email protected]>
Thanks, included.
Oleg.