This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tracepoint maintainance models


Alan Cox wrote:

Ar Llu, 2006-09-18 am 12:15 -0400, ysgrifennodd Frank Ch. Eigler:


[...] So its L1 misses more register reloads and the like. Sounds
more and more like wasted clock cycles for debug. [...]


But it's not just "for debug"! It is for system administrators,
end-users, developers.



It is for debug. System administrators and developers also do debug,
they may just use different tools. The percentage of schedule() calls
executed across every Linux box on the planet where debug is enabled is
so close to nil its noise. Even with traces that won't change.



Precisely the reason this huge thread is arguing why we shouldn't be including only static marker mechanism in the kernel tree. We are using dynamic probe mechanism which doesn't alter the execution flow or prevent compiler in making good optimizations for the most part but there are few code paths that are critical in understanding that we are not able to use this dynamic method for which we need static markers. As Martin pointed out if one is critical about performance they can be compiled out.


It is also important to note the amount of $s lost by taking long time to find a solution to a problem due to lack of good debugging tools is also significant compared to few additional clock cycles machines spend due to these static markers.



Indeed, there will be some non-zero execution-time cost. We must be
willing to pay *something* in order to enable this functionality.



There is an implementation which requires no penalty is paid. Create a new elf section which contains something like

[address to whack with int3]
[or info for jprobes to make better use]
[name for debug tools to find]
[line number in source to parse the gcc debug data]


I am not sure i quiet understand your line number part of the proposal. Does this proposal assume we have access to source code while generating dynamic probes?




This still doesn't solve the problem of compiler optimizing such that a variable i would like to read in my probe not being available at the probe point.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]