01:23 <irker772> systemtap: fche systemtap.git:refs/heads/master * release-4.1-68-g49fa913 / buildrun.cxx runtime/linux/autoconf-stack-trace-save-regs.c runtime/stack.c: PR24904: support linux 5.2's stacktrace.c changes http://tinyurl.com/yxbwcgr3

02:17 <irker772> systemtap: fche systemtap.git:refs/heads/master * release-4.1-69-gf4f0da6 / runtime/stack.c: PR24904: support linux 5.2's stacktrace.c changes with -DDEBUG_UNWIND too http://tinyurl.com/yykvx2d2

10:15 <gilfoyle> repeating the question: is it possible to identify if a given file descriptor is a socket or some other kind within systemtap? say, a write() syscall can be called with socket, file, device, etc. How could I identify the type of FD passed in?

11:13 <franks2> https://sourceware.org/ml/systemtap/2019-q3/msg00027.html Anyone have any a input?

12:53 <fche> gilfoyle, not as a general capability, but the pfiles.stp sample script makes kernel calls to determine

12:54 <fche> stap -i

12:55 <gilfoyle> cool :) thank you - is this pfiles.stp included in systemtap?

12:55 <fche> sample descriptors

12:55 <fche> i.e., try the interactive mode to navigate between samples - or use the web site

12:56 <fche> franks2, hey, no progress on that from me

12:56 <fche> but have you tried attaching a debugger to the php processes and intercept those same probe points?

12:56 <fche> (sorry don't recall if I advised the same already)

13:02 <franks2> Yes I did. The debugger finds it. However Im not familiar enougt with gdb to get the info from it

13:02 <gilfoyle> given centos/rhel 7 is probably lagging behind what systemtap's master has to offer, does anyone know how to get the documentation that matches the versions supplied with, e.g CentOS 7.4?

13:06 <fche> franks2, right, does gdb -stop-, with those breakpoints enabled?

13:06 <fche> i.e., are they ever hit?

13:23 <fche> gilfoyle, documentation pdfs etc. are included within the systemtap rpms

13:23 <fche> /usr/share/doc/systemtap* ; the man pages, examples

13:23 <fche> is there something you're not finding?

14:12 <gilfoyle> fche: was looking for a more comprehensive "getting started" sort of thing. I've been using on-and-off and often gleaning from several scripts I wrote along the years to get something out but then I never fully got to grips with the language and tools ecosystem

14:13 <fche> gilfoyle, yeah, there is a lot to know / learn just by diving in and gradually learning the lot

14:13 <fche> but yeah there is a systemtap tutorial, that's old but IMHO still good at getting all the concepts across

14:13 <fche> and a longer 'beginner's guide' pdf that's included in the rpms

15:28 <gilfoyle> thanks fche:)

21:12 <modem_> hey

21:13 <modem_> i am trying to profile a single kernel function and subroutines

21:13 <modem_> i am not sure how to identify which part is taking so many time

21:13 <modem_> does a systemtap script already exist ? I had poor result with perf, it seems the most time consuming things are the perf hook itself

21:13 <modem_> i might be doing something wront with perf

21:13 <modem_> but i am considering in using systemtap now

21:13 <modem_> thanks you

21:37 <modem_> il etait cool alladin

21:37 <modem_> aladin*

21:38 <fche> modem_, there are a couple of possible approaches

21:39 <fche> profiling a la random time sampling, and reversing PC addresses to source-line numbers -- that's one possibility

21:39 <fche> or actively probing each statement within a function, and then looking at relative hit counts as a proxy for time

21:39 <fche> the former case should interfere less, but get a random sampling

21:39 <fche> the latter case should interfere a ton, but get accurate counts

22:04 <modem_> fche: thanks a lot

22:04 <modem_> fche: is it possible to indicate probing each subroutines ?

22:16 <fche> there are a couple of ways

22:16 <fche> the most direct is to inspect the source code and put statement probes into each of the called subroutines too

22:17 <fche> probe function("foo").statement("*@*:*") {} kind of thing