50 Shades of System Calls
sysdig.com
50 Shades of System Calls
1–10 of 16 posts
Re: 50 Shades of System Calls
#2It is fun to observe that everyone might be busy tinkering with mentioned features instead of commenting.
Re: 50 Shades of System Calls
#3Nice work! I sometimes use strace/ltrace and this program would certainly be nice addition my toolbox!
One thing I find useful sometimes for debugging purposes is to actually see the contents of each system call. Do I get to see that when I click on individual boxes here?
Re: 50 Shades of System Calls
#4Nice work! I sometimes use strace/ltrace and this program would certainly be nice addition my toolbox! One thing I find useful sometimes for debugging purposes is to actually see the contents of each system call. Do I get to see that when I click on individual boxes here?
Blog post author here.
Yes, when you drill down using the mouse you will get the relevant system calls, including the buffers if they are I/O reads and writes.
Also, sysdig and csysdig have pretty advanced system call capture and filtering functionality. See this link for an introduction https://github.com/draios/sysdig/wiki/Sysdig%20User%20Guide
Re: 50 Shades of System Calls
#5Nice work! I sometimes use strace/ltrace and this program would certainly be nice addition my toolbox! One thing I find useful sometimes for debugging purposes is to actually see the contents of each system call. Do I get to see that when I click on individual boxes here?
Blog post author here. Yes, when you drill down using the mouse you will get the relevant system calls, including the buffers if they are I/O reads and writes. Also, sysdig and csysdig have pretty advanced system call capture and filtering functionality. See this link for an introduction https://github.com/draios/sysdig/wiki/Sysdig%20User%20Guide
Thanks for answering. Small suggestion - its kind of hard to find Github link. Perhaps make it more visible.
Re: 50 Shades of System Calls
#6Brilliant. (I note that the founder of this product co-authored the Winpcap packet capture library on Windows back in the day, and therefore made Ethereal/Wireshark on Windows possible.)
Re: 50 Shades of System Calls
#7Sysdig makes me giddy like dtrace used to.
I also sometimes feel a bit ... challenged ... by translating the questions I have (e.g. why did this arbitrary program start using a lot of memory and then OOM) into actual sysdig chisel invocations, but I'm learning slowly but surely. This command line spectrogram looks like a really nice addition to the existing toolset!
Re: 50 Shades of System Calls
#8This guy talks of 'latencies' when he really means 'durations'.
The latency is the time between stimulation and response, not the overall duration.
In this case the latency of a syscall would be the time between a user program performing a syscall and it starting to operate, not the entire time taken.
Re: 50 Shades of System Calls
#9This guy talks of 'latencies' when he really means 'durations'. The latency is the time between stimulation and response, not the overall duration. In this case the latency of a syscall would be the time between a user program performing a syscall and it starting to operate, not the entire time taken.
The way people talk about syscalls depends on your context/point of view. For example doing `open()` for the system is duration, because it does the work of opening a file. For the app, it may as well be latency - how long you're stopped before the file is opened.
Since the app doesn't actually execute the open code, it is latency -> from stimulation (called), to response (returned) is the latency of file access. For the system code latency would be waiting for the disk controller. For the disk controller latency would be waiting for the heads/platters.
Re: 50 Shades of System Calls
#10This guy talks of 'latencies' when he really means 'durations'. The latency is the time between stimulation and response, not the overall duration. In this case the latency of a syscall would be the time between a user program performing a syscall and it starting to operate, not the entire time taken.
The way people talk about syscalls depends on your context/point of view. For example doing `open()` for the system is duration, because it does the work of opening a file. For the app, it may as well be latency - how long you're stopped before the file is opened. Since the app doesn't actually execute the open code, it is latency -> from stimulation (called), to response (returned) is the latency of file access. For…
I would disagree with that interpretation. I would talk about the duration of the open() call, in the same way as when you're optimising code, you talk about the duration of a function call, not its latency.
Sadly, misuse of the term is rife in software circles.
Latency is correctly used when talking about how long an ISR takes to start running when provoked by an external stimulus, or how long it takes for a task to be scheduled when made ready.
Latency is a very precise term. a syscall, as its name suggests is a 'call', and 'calls' are not considered to be instantaneous.
(Edit: instantaneous, not atomic)
Duration is the correct term for syscalls.