0

So I am writing a profiler and the time the threads were not executing is relevant to my calculation. However, all the libraries I know provide the time for which the threads were executing e.g getrusage.

getrusage returns the time the threads were executing, so if I can somehow get the time elapsed since the thread was made (or the time the thread was made at), in principle, I can subtract getrusage's time from it and that will be the blocking time?

I instrument the code to know my metrics through an LLVM pass.

Dev2017
  • 857
  • 9
  • 31
  • One big thorn is that an OS can switch tasks without the task's knowledge. So your profiler, nor any threads, can determine when they they were swapped out. You may have to dive into the operating system to see if there are any *hooks* that get called before and after a task is swapped. – Thomas Matthews Feb 20 '17 at 15:35
  • BTW, your issue is with operating systems. What operating system are you targeting? There is no standard for managing tasks among operating systems, so your question is highly OS specific. – Thomas Matthews Feb 20 '17 at 15:36
  • Linux based ones. I am testing on Ubuntu 14.04. – Dev2017 Feb 20 '17 at 15:37
  • @ThomasMatthews please check my edit in the question. Hope it helps you in helping me :) – Dev2017 Feb 20 '17 at 16:16
  • Look at the source code for Linux, especially the area the performs task swapping. Determine if you can hook another function (daisy chain) to the calls before it swaps a task and after. – Thomas Matthews Feb 20 '17 at 17:57
  • is it possible to know the time when the thread was made? – Dev2017 Feb 20 '17 at 17:59
  • Well, [*I do it manually*](http://stackoverflow.com/a/378024/23771), but if I had to automate it, I would set a timer (one that works on wall-clock time, not CPU time), and when it went interrupted I would grab a stack sample. If it's doing I/O or hanging on a mutex, that can be seen by where it is. If 100 samples are taken, some % of them will be in that state. What's more, even if competing processes inflate the time the program under test takes, that does not change the measured % very much, except maybe to lower it as the disk speeds up, in relative terms. – Mike Dunlavey Feb 20 '17 at 20:10

0 Answers0