Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sampling frequency cannot be guaranteed #177

Open
viglia opened this issue Nov 15, 2022 · 0 comments
Open

Sampling frequency cannot be guaranteed #177

viglia opened this issue Nov 15, 2022 · 0 comments

Comments

@viglia
Copy link
Contributor

viglia commented Nov 15, 2022

Hi,

I don't know if this issue should be labelled as a "bug" since it's due to the way sampling is implemented but we probably should make clear in the docs that the sampling frequency is "indicative" and not real.

From the README:

When profiling was started, setitimer system call was used to 
set up a timer which will send a SIGPROF to this program 
every constant interval.

When receiving a SIGPROF signal, the signal handler will capture 
a backtrace and increase the count of it. 

etc. etc.

If we check the Execution of signal handlers section of the Linux Manual Page though, it explains that:

   Execution of signal handlers
       Whenever there is a transition from kernel-mode to user-mode
       execution (e.g., on return from a system call or scheduling of a
       thread onto the CPU), the kernel checks whether there is a
       pending unblocked signal for which the process has established a
       signal handler.  If there is such a pending signal, the following
       steps occur:

This has 2 consequences:

  1. we cannot guarantee when and how often a sample is collected
  2. depending on the nature of the work being executed in a thread, sampling might be biased toward certain threads at the expense of others

In my experiments I have indeed come across the 2 points I've mentioned above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant