A uprobes addendum

Posted Jan 25, 2010 12:55 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: A uprobes addendum by njs
Parent article: A uprobes addendum

I don't really care about DTrace itself, I just want a similar functionality.

I.e. an integrated tracing system for userspace and kernel programs. From what I see, my wish won't be real for quite a some time.

SystemTap really looked nice, but if it's not going to be merged into the kernel, I won't bother start using it.

A uprobes addendum

Posted Jan 25, 2010 18:20 UTC (Mon) by adobriyan (subscriber, #30858) [Link] (3 responses)

> I don't really care about DTrace itself, I just want a similar
functionality.

This sentence could be automatically added to every post mentioning DTrace
as a signature :)

> I.e. an integrated tracing system for userspace and kernel programs. From
what I see, my wish won't be real for quite a some time.

Now let's define what "integrated tracing system" means.

A uprobes addendum

Posted Jan 25, 2010 19:41 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

For example, administrators should be able to use the same tool to check which process holds most of paged-out memory pages and to check which client holds most connections to PostgreSQL.

A uprobes addendum

Posted Jan 26, 2010 11:09 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

While I really like systemtap and wish it, or something like it, could be integrated, this is not the most compelling use case one could come up with. 'Who has the largest ps(1) SWAP column' and 'who has most PostgreSQL connections' are not obviously related, and I can't imagine anyone thinking that the same tool should be able to answer both questions (not least since the first question can easily be answered *now*).

However, questions like 'why is my PostgreSQL backend suddenly spending most of its time doing IPC to nothing obvious' are basically impossible to answer now without killing the backend and hacking the source code, which would tend to perturb the answer because whatever perturbation of dynamic state was causing this would necessarily be lost when the process was restarted. With systemtap/dtrace annotations and a few taps in easy (even for kernel idiots like me) to figure out places in the kernel, it was trivial to answer.

A uprobes addendum

Posted Jan 26, 2010 22:52 UTC (Tue) by fuhchee (guest, #40059) [Link]

"With systemtap/dtrace annotations and a few taps in easy (even for kernel idiots like me) to figure out places in the kernel, it was trivial to answer."

Would you mind posting more details about your story?

A uprobes addendum

Posted Jan 26, 2010 19:09 UTC (Tue) by fuhchee (guest, #40059) [Link]

"SystemTap really looked nice, but if it's not going to be merged into the kernel, I won't bother start using it."

Systemtap itself does not require integration into the kernel tree in order to operate, so don't hold back. This fact appears to bother some sufficiently to impede acceptance of other kernel infrastructure that, among other valid uses, also happens to help users of systemtap.