Another point is that unlike strace, SystemTap's system-wide, and being kernel side instead of going through the fragile (threads/signals...) & slow ptrace() interface it can be much faster, especially after it starts using the static markers / tracepoints.  One can attach strace to multiple processes, but it really slows down the system and is pretty inconvenient (ptrace has side-effects). If one wants to do full system tracing, currently LTT is much better alternative than SystemTap though due to its much smaller overhead (especially with multiple probes). LTT and SystemTap are a bit for different purposes though. Currently neither LTT nor SystemTap provide user-space tracing like DTrace does, but I think Frysk does some of that. Frysk doesn't do kernel tracing though and it would also profit from utrace as currently it uses ptrace(). (Note: ltrace tool is pretty useless for user-space tracing as it doesn't trace library->library calls and it doesn't support dlopen() which is used almost by anything a bit more complicated on Linux desktop). Once one has system wide monitoring, one could have something like this: - http://idea.opensuse.org/content/ideas/filemon-like-syste... - Or the RedHat Google SOC about getting BootChart type of visuals from SystemTap... PS. This is not just DTrace envy, it would be nice to have a GUIs like these: http://developer.apple.com/tools/performance/optimizingwi... http://developer.apple.com/documentation/DeveloperTools/C... (Instruments uses DTrace, Shark doesn't) :-) Btw. This is more about performance analysis framework stuff than tracing, but what is happening with perfmon2? Is that going to be used e.g. by LTT?
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds