<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Sorry to revive this old thread, and thank you for the suggestions given, but I've been trying to make these work for my case with little success and I need a hand to understand what I'm doing wrong.<br></div><div><br></div><div>Regarding bpftrace: This seemed like the best option since I could use it to count frames of the stack with depth 2, allowing me to know precisely the amount of times each specific call has been made. However, I could not use it because since I have to probe every function, it would raise an error related to open file limit. I've tried setting the open file limit to unlimited, but the command I used to do so said it was impossible, also the current limit is set to 1048576, so I'm guessing that probing every function isn't a viable solution.</div><div><br></div><div>Regarding perf: I couldn't find out how to count each call with perf, but I could count how many times each function was called. Differently from bpftrace, I need to use a command for each function I would like to probe, so I created a script that would get all the functions that can be probed and call that command for each of them. Unfortunately this took too long, so I stopped after a certain number of probes were created and executed my test, at that time, the machine hanged.</div><div>With a low number of functions being probed it worked fine though.</div><div><br></div><div>Right now, the solution I can see is using bpftrace to probe a very limited number of calls, profile an execution, then repeat the profile for different set of probes, which can take a very long time.</div><div>Is there an easier way (less time consuming) to achieve the same results (counting how many times each call instruction has been executed)?</div><div><br></div><div>Thanks you for the attention,<br></div><div>Pedro<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 3, 2019 at 6:23 PM Augusto Mecking Caringi <<a href="mailto:augustocaringi@gmail.com" target="_blank">augustocaringi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Wed, Apr 3, 2019 at 9:26 PM Pedro Terra Delboni <<a href="mailto:terra0009@gmail.com" target="_blank">terra0009@gmail.com</a>> wrote:<br>
><br>
> Hello!<br>
><br>
> I have a question about profiling, please, let me know if this is not<br>
> the right mailing list to post these kind of questions.<br>
><br>
> Is there a way for me to record how many times each specific direct<br>
> call to a function happened?<br>
> I've seen ways of profiling the kernel that calculate how much time<br>
> the system spent in each function, but having a bit more information<br>
> related to calls would be really good.<br>
><br>
> I would like to know, for every function call that happens in run<br>
> time, who called it (it's for a project in my University).<br>
><br>
> I've also seen (I may be mistaken here) that by compiling the kernel<br>
> with perf, each function will start with a stub call which can be used<br>
> for profiling purposes.<br>
> I was thinking in using this stub to plug a function to dump<br>
> (somewhere) the return address before it's own (so I can collect the<br>
> info about where the call came from).<br>
> I wonder if changing every stub calls in all functions to dump its<br>
> return address wouldn't create too much of a latency impact to the<br>
> point of skewing the control flow of the execution,<br>
> or even making it nonviable.<br>
><br>
> Thanks in advance, any help would be great!<br>
> If this is not the right place to post this question, I would<br>
> appreciate if anyone could point me to the right place.<br>
<br>
There is also a new tool called bpftrace that can help you...<br>
<br>
<a href="https://github.com/iovisor/bpftrace" rel="noreferrer" target="_blank">https://github.com/iovisor/bpftrace</a><br>
<br>
Regards,<br>
<br>
-- <br>
Augusto Mecking Caringi<br>
</blockquote></div>
</div>